Tactical RMM en un VPS: tu propio sistema de administración remota

Qué configuramos y por qué

Tactical RMM es un sistema de monitorización y gestión remota de dispositivos finales. Suele ser utilizado por administradores de sistemas, pequeños equipos de IT, proveedores MSP, desarrolladores y propietarios de varios servidores o estaciones de trabajo. A diferencia del acceso SSH habitual, una plataforma RMM muestra el estado de todas las máquinas en un único panel, puede ejecutar automatizaciones programadas y registra las acciones de los operadores.

Después de configurarlo en un VPS, dispondrá de un panel web donde podrá agrupar dispositivos por clientes, sitios y roles. Por ejemplo, gestionar por separado los equipos de oficina, servidores de aplicaciones, portátiles de desarrolladores y máquinas virtuales de prueba. Se instala un agente Tactical RMM en los dispositivos; este transmite telemetría, recibe comandos y ejecuta las comprobaciones asignadas.

Qué puede hacer Tactical RMM

• Inventario de hardware, SO, discos, servicios y software instalado.
• Monitorización de disponibilidad, uso de CPU, RAM, espacio en disco y comprobaciones personalizadas.
• Ejecución remota de scripts PowerShell, Bash, Python y otros.
• Programador de tareas: actualizaciones, limpieza de archivos temporales, reinicio de servicios e inventario.
• Acceso remoto mediante MeshCentral y soporte para sesiones de terminal.
• Alertas por e-mail, webhooks e integraciones con sistemas externos.
• Gestión de parches de Windows y procedimientos de mantenimiento.
• Auditoría de acciones de operadores e historial de resultados de scripts.

Por qué no un RMM en la nube

Un RMM gestionado en la nube resulta cómodo porque no requiere mantenimiento de la parte del servidor. Sin embargo, en este modelo, los datos sobre dispositivos, nombres de host, usuarios, direcciones IP y escenarios de automatización pasan por la infraestructura de un proveedor externo. Además, el coste de la suscripción normalmente aumenta junto con el número de agentes.

Un Tactical RMM self-hosted proporciona control sobre los datos, DNS, certificados, periodo de retención de registros y acceso de los operadores. Es útil para infraestructura interna, pequeños equipos MSP, laboratorios, entornos homelab y organizaciones con requisitos sobre la ubicación de los datos. La desventaja es que el servidor, las actualizaciones, la seguridad y las copias de seguridad pasan a ser su responsabilidad.

Importante: un servidor RMM tiene acceso privilegiado a los dispositivos administrados. La vulneración del panel implica el riesgo de comprometer toda la infraestructura. Utilice contraseñas únicas, MFA, restricciones de acceso, actualizaciones periódicas y copias de seguridad.

Qué configuración de VPS se necesita para esta tarea

La carga de Tactical RMM depende no solo del número de agentes, sino también de la frecuencia de las comprobaciones, la retención de registros, el número de sesiones remotas simultáneas, el volumen de automatización y el uso de MeshCentral. Para empezar, no conviene elegir un VPS con 1–2 GB de RAM: PostgreSQL, los contenedores de la aplicación, el broker de mensajes y el servicio de acceso remoto competirán por la memoria.

Una opción inicial práctica es 4 vCPU, 8 GB de RAM, 120 GB NVMe y una conexión de al menos 100 Mbit/s. Este margen permite gestionar decenas de agentes, conservar el historial de comprobaciones y evitar OOM constantes durante las actualizaciones de contenedores. Como una de las opciones, puede elegir un VPS con las características indicadas, pero más importante es contar con SSD/NVMe, IPv4 estática, una red estable y la posibilidad de realizar snapshots.

Disco y red

Para la base de datos, la latencia y los IOPS son más importantes que una gran capacidad de HDD lento. Mantenga libre al menos el 30–40% del disco: PostgreSQL, los registros de contenedores, los archivos temporales y las copias de seguridad pueden llenar rápidamente la partición. Si el panel tiene muchos dispositivos con comprobaciones frecuentes, configure con antelación la rotación de registros de Docker.

El tráfico saliente suele ser moderado, pero aumenta durante las sesiones remotas, transferencias de archivos e instalación masiva de agentes. Para 50–100 dispositivos, 100 Mbit/s es suficiente, aunque 1 Gbit/s es preferible para acceso remoto frecuente. Compruebe que el proveedor no bloquee los puertos entrantes 80/TCP y 443/TCP: son necesarios para emitir y renovar certificados TLS.

Cuándo se necesita un dedicated en lugar de un VPS

Un servidor dedicated tiene sentido con cientos de agentes, uso intensivo de escritorio remoto, retención prolongada de registros, requisitos de recursos dedicados o políticas estrictas de aislamiento. También es útil si en la misma plataforma funcionan sistemas de monitorización independientes, una puerta de enlace VPN, almacenamiento de archivos y una copia de seguridad de la base de datos.

Para 20–150 dispositivos, un VPS de calidad suele ser más sencillo y económico. Es mejor comenzar el escalado no migrando a un servidor dedicado, sino optimizando los intervalos de comprobación, limpiando el historial, externalizando las copias de seguridad y aumentando la RAM. No aloje Tactical RMM en un VPS que también actúe como sitio web público, servidor de correo y base de datos de una aplicación crítica.

Elección de ubicación

La ubicación influye en la latencia de las sesiones remotas, los requisitos de jurisdicción de datos y la velocidad de conexión de los agentes. Si la mayoría de los empleados se encuentra en Europa, elija un centro de datos europeo; para un equipo local en una región, es preferible mantener el servidor cerca de él. Al mismo tiempo, los agentes se conectan mediante HTTPS, por lo que la ubicación física del dispositivo en otro país no supone un problema si la conexión es estable.

Preparación del servidor

A continuación se utiliza Ubuntu Server 24.04 LTS. En 2026, es una plataforma LTS actual con un largo periodo de soporte. Despliegue el servidor desde una imagen limpia, asígnele un nombre de dominio completo y cree registros DNS de tipo A antes de la instalación.

Como ejemplo se utilizarán tres subdominios:

• rmm.example.com — panel web de Tactical RMM.
• api.rmm.example.com — API y registro de agentes.
• mesh.rmm.example.com — MeshCentral para acceso remoto.

Sustituya example.com por su propio dominio en todos los comandos y archivos de configuración. Los tres registros deben apuntar a la dirección IPv4 pública del VPS antes de obtener los certificados.

Creación del administrador y configuración de SSH

Conéctese al servidor como root solo una vez, cree un usuario independiente y añada su clave pública SSH. Después de verificar el acceso con el nuevo usuario, desactive la autenticación por contraseña.

# Создаёт отдельного пользователя для администрирования.
adduser deploy

# Добавляет пользователя в группу sudo.
usermod -aG sudo deploy

# Создаёт каталог для SSH-ключей.
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

# Добавляет ваш публичный ключ; замените содержимое ключом из ~/.ssh/id_ed25519.pub.
nano /home/deploy/.ssh/authorized_keys

# Устанавливает безопасные права на файл ключей.
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

Abra una segunda sesión SSH y asegúrese de que el acceso con el usuario deploy funciona. Solo después cambie la configuración de SSH.

# Открывает настройки SSH-демона.
sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

# Проверяет синтаксис конфигурации SSH.
sudo sshd -t

# Перезапускает SSH после успешной проверки.
sudo systemctl restart ssh

Coloque lo siguiente en el archivo /etc/ssh/sshd_config.d/99-hardening.conf:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
AllowUsers deploy

Actualización y utilidades básicas

Primero instale las actualizaciones. Tactical RMM es un servicio que estará disponible desde internet, por lo que no posponga las correcciones del kernel, OpenSSL, Docker y el servidor web.

# Обновляет индекс пакетов и устанавливает актуальные исправления.
sudo apt update && sudo apt full-upgrade -y

# Устанавливает базовые инструменты диагностики и администрирования.
sudo apt install -y ca-certificates curl gnupg git jq unzip \
  htop ncdu dnsutils chrony ufw fail2ban

# Включает синхронизацию времени, важную для TLS и журналов.
sudo systemctl enable --now chrony

# Проверяет текущую синхронизацию времени.
timedatectl status

Firewall y Fail2ban

Abra únicamente SSH y los puertos web. No exponga PostgreSQL, NATS, Redis, las API internas ni los puertos de contenedores a internet. Los contenedores Docker deben estar disponibles mediante un reverse proxy o la red interna de Compose.

# Разрешает SSH до включения firewall, чтобы не потерять доступ.
sudo ufw allow OpenSSH

# Разрешает HTTP для ACME-проверки и HTTPS для панели и агентов.
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Включает firewall и показывает активные правила.
sudo ufw enable
sudo ufw status verbose

# Включает Fail2ban для защиты SSH от перебора паролей.
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Si administra el servidor únicamente desde una dirección IP permanente, restrinja también SSH a esa dirección. No lo haga con una IP doméstica dinámica sin acceso de emergencia a través de la consola del proveedor.

# Пример: разрешает SSH только с доверенного IP-адреса.
sudo ufw delete allow OpenSSH
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Instalación del software — paso a paso

Tactical RMM consta de varios servicios: la aplicación web, API, PostgreSQL, un broker de mensajes, MeshCentral y componentes de tareas en segundo plano. La vía más segura es utilizar el instalador oficial del proyecto, que crea una configuración y contenedores coherentes. Antes de ejecutarlo, lea el contenido del script descargado: se ejecuta con privilegios de root.

Este esquema utiliza Docker Engine 27+ o 28+ y un Docker Compose plugin moderno. Las versiones de las imágenes de Tactical RMM cambian más rápido que las versiones de Ubuntu, por lo que no fije manualmente una etiqueta no probada: el instalador oficial normalmente selecciona una versión estable compatible.

Instalación de Docker Engine

# Elimina paquetes antiguos de Docker que entren en conflicto, si están presentes.
sudo apt remove -y docker.io docker-compose docker-compose-v2 podman-docker || true

# Añade la clave oficial del repositorio de Docker.
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Añade el repositorio oficial de Docker para la versión actual de Ubuntu.
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Instala Docker Engine, CLI y el plugin Docker Compose.
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

# Habilita Docker y comprueba la versión instalada.
sudo systemctl enable --now docker
docker version
docker compose version

Permita al usuario deploy trabajar con Docker sin usar constantemente sudo. Después de ejecutar el comando, cierre la sesión SSH y vuelva a conectarse.

# Añade al administrador al grupo docker.
sudo usermod -aG docker deploy

# Crea un directorio para la instalación y el mantenimiento de Tactical RMM.
sudo install -d -m 0750 -o deploy -g deploy /opt/tacticalrmm

Comprobación de DNS antes de la instalación

Los registros DNS incorrectos son una de las causas más frecuentes de un fallo al emitir un certificado TLS. Compruebe cada subdominio desde el propio VPS y desde un equipo externo. El comando debe devolver la IP pública del servidor.

# Comprueba que todos los nombres de dominio apuntan a la IP del VPS.
dig +short rmm.example.com A
dig +short api.rmm.example.com A
dig +short mesh.rmm.example.com A

# Muestra la dirección IP pública con la que el VPS accede a Internet.
curl -4 ifconfig.me

Descarga del instalador oficial de Tactical RMM

El proyecto oficial mantiene un script de instalación en el repositorio de Tactical RMM. Antes de ejecutarlo, guárdelo localmente, revise las primeras líneas y, si es necesario, estudie el código completo. No utilice construcciones de una sola línea como curl | bash para servidores que administre en producción.

# Va al directorio de trabajo de la instalación.
cd /opt/tacticalrmm

# Descarga el script de instalación oficial en un archivo local.
curl -fL \
  https://raw.githubusercontent.com/amidaware/tacticalrmm/master/install.sh \
  -o install.sh

# Permite la ejecución y muestra el inicio del archivo para revisión manual.
chmod 700 install.sh
sed -n '1,120p' install.sh

# Muestra las opciones si el script admite ayuda integrada.
sudo ./install.sh --help || true

Los nombres de los parámetros del instalador pueden cambiar entre versiones. Si el script ofrece un modo interactivo, elija la instalación con Docker e indique tres FQDN: para el panel, la API y MeshCentral. Durante el proceso necesitará un e-mail para Let’s Encrypt y contraseñas seguras para los servicios internos.

# Ejecuta el instalador interactivo oficial con privilegios de root.
sudo ./install.sh

Durante la instalación, indique:

• dominio del panel: rmm.example.com;
• dominio de la API: api.rmm.example.com;
• dominio de MeshCentral: mesh.rmm.example.com;
• e-mail para las notificaciones de Let’s Encrypt;
• secretos aleatorios y únicos para la base de datos, JWT y componentes internos;
• la IP pública del VPS, si el instalador la solicita por separado.

Comprobación de contenedores

Después de finalizar, no considere la instalación lista hasta comprobar el estado de los servicios. Los contenedores pueden tardar varios minutos en iniciarse, especialmente durante la primera creación de la base de datos y la emisión del certificado.

# Muestra el estado de los servicios en el directorio de instalación.
cd /opt/tacticalrmm
docker compose ps

# Muestra las últimas 200 líneas de los registros de todos los contenedores.
docker compose logs --tail=200

# Comprueba que el servidor escucha solo los puertos HTTP/HTTPS externos esperados.
sudo ss -lntp | grep -E ':(80|443)\s'

# Comprueba el espacio libre y el uso de memoria.
df -h
free -h

Abra https://rmm.example.com en el navegador. En el primer acceso, cree el administrador solo con una contraseña única y larga. Después, habilite MFA para todos los operadores, cree cuentas separadas para los empleados y no utilice una cuenta de administrador compartida.

Configuración

Después de la instalación básica, configure los dominios, secretos, TLS, parámetros de registro y acceso de los operadores. Los nombres concretos de los archivos dependen de la versión del instalador oficial, pero el principio es el mismo: los secretos no deben llegar al repositorio Git, al historial de shell, a capturas de pantalla ni a servicios públicos de paste.

Archivo de entorno y secretos

Si su deployment utiliza Docker Compose, almacene los secretos en un archivo .env separado con permisos 600. No pase contraseñas mediante argumentos de línea de comandos: pueden llegar al historial de shell y a la lista de procesos.

# Crea un directorio de configuración accesible solo para root.
sudo install -d -m 0700 /etc/tacticalrmm

# Genera secretos criptográficamente seguros.
sudo bash -c 'umask 077; cat > /etc/tacticalrmm/.env <<EOF
POSTGRES_PASSWORD='$(openssl rand -base64 36)'
DJANGO_SECRET_KEY='$(openssl rand -base64 48)'
JWT_SECRET='$(openssl rand -base64 48)'
EOF'

# Restringe el acceso al archivo de secretos.
sudo chmod 600 /etc/tacticalrmm/.env
sudo chown root:root /etc/tacticalrmm/.env

No sustituya los secretos existentes por otros nuevos después de una instalación operativa sin comprender su propósito. Cambiar la clave de la aplicación o JWT puede finalizar las sesiones activas, y sustituir la contraseña de la base de datos sin cambiar simultáneamente la configuración detendrá el servicio.

TLS mediante Caddy

En muchas variantes de instalación de Tactical RMM, Caddy ya se utiliza como reverse proxy. Si el instalador creó un Caddyfile, compruebe que solo redirige los servicios necesarios, habilita HTTPS y no publica paneles internos de PostgreSQL o NATS.

A continuación se muestra un ejemplo de la estructura general de un Caddyfile. Verifique los puertos de los contenedores y las rutas de la API con los archivos creados por su versión de Tactical RMM. No copie el ejemplo a ciegas sobre un Caddyfile operativo: primero guarde una copia de seguridad.

Caddyfile {
    email [email protected]
    servers {
        protocols h1 h2
    }
}

rmm.example.com {
    encode zstd gzip
    reverse_proxy tactical-frontend:8000
}

api.rmm.example.com {
    encode zstd gzip
    reverse_proxy tactical-api:8001
}

mesh.rmm.example.com {
    encode zstd gzip
    reverse_proxy meshcentral:4430
}

Antes de aplicar cualquier configuración de Caddy, compruebe la sintaxis. Si Caddy se ejecuta dentro de Docker, utilice el nombre del contenedor o los comandos de Compose; si está instalado como servicio systemd, utilice el comando del sistema.

# Guarda una copia del Caddyfile actual antes de editarlo.
sudo cp /etc/caddy/Caddyfile /etc/caddy/Caddyfile.bak.$(date +%F) 2>/dev/null || true

# Comprueba la configuración de Caddy instalado localmente.
sudo caddy validate --config /etc/caddy/Caddyfile 2>/dev/null || true

# Recarga Caddy sin interrumpir las conexiones activas.
sudo systemctl reload caddy 2>/dev/null || true

Comprobación de HTTPS y API

Compruebe no solo que la página se abra en el navegador, sino también la corrección de la cadena TLS, DNS, la respuesta HTTP y la disponibilidad de la API. Una respuesta 200, 301, 302 o 401 en un endpoint protegido normalmente significa que el reverse proxy funciona; un error 502 indica que el contenedor backend no está disponible.

# Comprueba las cabeceras de la página principal y la conexión TLS.
curl -I --fail --max-time 15 https://rmm.example.com

# Comprueba que la API responde mediante HTTPS.
curl -I --max-time 15 https://api.rmm.example.com

# Comprueba el certificado, el nombre de host y la fecha de caducidad.
echo | openssl s_client -connect rmm.example.com:443 \
  -servername rmm.example.com 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

# Comprueba la disponibilidad de MeshCentral mediante HTTPS.
curl -I --max-time 15 https://mesh.rmm.example.com

Configuración inicial en el panel web

1. Cree una organización o cliente independiente para su propia infraestructura.
2. Cree sitios: por ejemplo, Office, Production, Home Lab.
3. Cree grupos técnicos de dispositivos: Windows Servers, Linux Servers, Workstations.
4. Habilite MFA para el administrador antes de desplegar los agentes.
5. Configure SMTP o webhook para las notificaciones críticas.
6. Cree una comprobación de espacio libre: advertencia al 15%, nivel crítico al 5%.
7. Añada una máquina de prueba y compruebe la ejecución de un comando seguro.

Para realizar una prueba en Linux, asigne un script que no modifique el sistema:

# Muestra el nombre de host, uptime, espacio libre y versión del kernel.
hostnamectl
uptime
df -h /
uname -r

Para Windows, utilice un script de PowerShell:

# Muestra el nombre del equipo, la versión del SO y el espacio libre en la unidad del sistema.
Get-ComputerInfo | Select-Object CsName, WindowsProductName, WindowsVersion
Get-PSDrive -Name C | Select-Object Name, Used, Free

Seguridad de los agentes: instale el agente solo mediante el panel protegido, no coloque el installer en un directorio de archivos abierto y no deshabilite la comprobación de certificados. Para los servidores, primero pruebe los scripts en una sola máquina dentro de un grupo independiente.

Copias de seguridad y mantenimiento

La instantánea del VPS es útil, pero no sustituye a una copia de seguridad. Puede encontrarse en el mismo centro de datos, no estar disponible en caso de error de la cuenta y no garantizar la consistencia de la base de datos durante la escritura. Para Tactical RMM se necesitan como mínimo copias de seguridad diarias de PostgreSQL, de la configuración del reverse proxy, de los archivos Compose, de las variables de entorno y de los Docker volumes persistentes.

Qué incluir en la copia de seguridad

• Volcado de PostgreSQL: usuarios, organizaciones, agentes, políticas, historial y configuración.
• Directorio de instalación /opt/tacticalrmm, excepto los archivos temporales innecesarios y los registros de gran tamaño.
• Configuraciones de /etc/tacticalrmm, /etc/caddy y los archivos unit de systemd relacionados.
• Lista de Docker volumes y datos de MeshCentral, si no están incluidos en el volcado de la base de datos.
• Documento con los dominios, registros DNS, lista de operadores y procedimiento de recuperación.

Copia de seguridad mediante restic

Restic admite el cifrado en el lado del cliente y almacenes compatibles con S3. No almacene la contraseña del repositorio ni las claves de acceso en la propia copia de seguridad. Guárdelas en un password manager o en un almacén de secretos accesible durante la recuperación ante desastres.

# Устанавливает restic и утилиты PostgreSQL-клиента.
sudo apt install -y restic postgresql-client

# Создаёт каталоги для временных дампов и конфигурации бэкапов.
sudo install -d -m 0700 /var/backups/tacticalrmm /etc/restic

# Создаёт файл с паролем шифрования репозитория.
sudo bash -c 'umask 077; openssl rand -base64 48 > /etc/restic/tacticalrmm-password'

# Создаёт файл переменных для S3-совместимого хранилища.
sudo nano /etc/restic/tacticalrmm.env

Ejemplo del archivo /etc/restic/tacticalrmm.env:

export RESTIC_REPOSITORY="s3:https://s3.example.net/tacticalrmm-backups"
export RESTIC_PASSWORD_FILE="/etc/restic/tacticalrmm-password"
export AWS_ACCESS_KEY_ID="CHANGE_ME"
export AWS_SECRET_ACCESS_KEY="CHANGE_ME"
export AWS_DEFAULT_REGION="us-east-1"

Cree el script. Confirme el nombre del contenedor de PostgreSQL mediante docker compose ps; en el ejemplo se busca por el nombre del servicio. Si su instalación utiliza otro esquema, sustituya el comando de volcado por el correspondiente.

# Создаёт ежедневный скрипт консистентного бэкапа.
sudo nano /usr/local/sbin/backup-tacticalrmm.sh

#!/usr/bin/env bash
set -euo pipefail

source /etc/restic/tacticalrmm.env

STAMP="$(date +%F_%H-%M-%S)"
BACKUP_DIR="/var/backups/tacticalrmm/${STAMP}"
mkdir -p "${BACKUP_DIR}"

cd /opt/tacticalrmm

docker compose exec -T postgres pg_dump -U postgres -Fc \
  tacticalrmm > "${BACKUP_DIR}/tacticalrmm.dump"

tar -czf "${BACKUP_DIR}/config.tar.gz" \
  /opt/tacticalrmm \
  /etc/tacticalrmm \
  /etc/caddy 2>/dev/null || true

restic backup "${BACKUP_DIR}" \
  --tag tacticalrmm \
  --tag daily

restic forget --prune \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12

rm -rf "${BACKUP_DIR}"

# Делает скрипт исполняемым и запускает тестовый бэкап вручную.
sudo chmod 700 /usr/local/sbin/backup-tacticalrmm.sh
sudo /usr/local/sbin/backup-tacticalrmm.sh

# Проверяет содержимое и целостность репозитория restic.
sudo bash -c 'source /etc/restic/tacticalrmm.env; restic snapshots'
sudo bash -c 'source /etc/restic/tacticalrmm.env; restic check'

Añada una ejecución nocturna mediante cron. Con una base de datos grande, es mejor utilizar un systemd timer, ya que registra mejor los eventos y puede ejecutar las tareas omitidas después de un reinicio, pero cron es suficiente para una instalación pequeña.

# Открывает root-crontab для ежедневного запуска в 03:20.
sudo crontab -e

20 3   * /usr/local/sbin/backup-tacticalrmm.sh >> /var/log/tacticalrmm-backup.log 2>&1

Comprobación de la recuperación

Una copia de seguridad solo se considera operativa después de probar la recuperación. Una vez por trimestre, implemente un VPS temporal independiente, restaure la configuración y la base de datos y, a continuación, compruebe el acceso al panel y la visibilidad de los dispositivos de prueba. No realice la primera restauración durante una emergencia.

Actualizaciones

Para Tactical RMM, utilice una maintenance window, especialmente si hay servidores de clientes conectados. Las actualizaciones pueden cambiar el esquema de la base de datos, las versiones de los contenedores y el comportamiento de los agentes. Primero cree una copia de seguridad reciente, lea las release notes, pruebe la actualización en una copia o instalación de prueba y solo después actualice production.

# Сохраняет состояние работающих образов перед обновлением.
cd /opt/tacticalrmm
docker compose images > /root/tacticalrmm-images-before-update.txt

# Создаёт бэкап перед изменением версий.
sudo /usr/local/sbin/backup-tacticalrmm.sh

# Загружает новые образы и применяет обновление по документации выпуска.
docker compose pull
docker compose up -d

# Проверяет состояние и последние журналы после обновления.
docker compose ps
docker compose logs --tail=150

No realice actualizaciones automáticas de contenedores mediante Watchtower o herramientas similares sin realizar pruebas. Para RMM es preferible una actualización controlada durante una ventana acordada, porque una breve interrupción del panel o una incompatibilidad de la base de datos pueden afectar a numerosos agentes.

Solución de problemas y FAQ

¿Por qué el navegador muestra un error de certificado o Caddy no obtiene el certificado?

Primero compruebe el DNS: cada subdominio debe devolver la IPv4 pública del VPS. Después asegúrese de que los puertos 80/TCP y 443/TCP estén accesibles desde el exterior y que el firewall y el security group externo no los bloqueen. Consulte los registros de Caddy o del reverse proxy mediante docker compose logs. Una causa frecuente es que el registro AAAA apunte a un servidor IPv6 que no funciona o que otro servidor web ya esté ocupando el puerto 80.

¿Por qué el panel se abre, pero la API responde con el error 502 Bad Gateway?

El código 502 significa que el reverse proxy funciona, pero no puede conectarse al servicio backend. Ejecute docker compose ps y busque el contenedor con estado exited, restarting o unhealthy. Después abra sus registros: docker compose logs --tail=200 имя_сервиса. Compruebe la RAM, el espacio libre en disco, los valores de las variables de entorno y la disponibilidad de PostgreSQL. No elimine los volúmenes antes de crear una copia de seguridad.

¿El agente de Tactical RMM no se registra o permanece constantemente offline? ¿Qué hacer?

Compruebe que la máquina del cliente pueda abrir https://api.rmm.example.com y https://mesh.rmm.example.com sin errores de TLS. El proxy corporativo, el antivirus, el EDR o el firewall pueden bloquear la comunicación del agente. Verifique la hora del dispositivo: una diferencia considerable en el reloj puede impedir la validación de los certificados. Asegúrese también de que el instalador del agente se haya descargado desde el panel actual y utilice la URL correcta de la API, no un dominio antiguo.

Después de iniciar los contenedores, el servidor comienza a utilizar swap o los servicios se reinician.

Normalmente, la causa es la falta de RAM. Compruebe free -h, docker stats, dmesg -T | grep -i oom y el tamaño de los registros de Docker. Para un funcionamiento estable de una instalación pequeña se recomiendan 8 GB de RAM; 4 GB solo son adecuados para una carga de laboratorio. Temporalmente puede aumentar la swap, pero no sustituye a la memoria: PostgreSQL y los servicios de RMM funcionarán más lentamente. Reduzca el número de comprobaciones pesadas y actualice la configuración del VPS.

El disco se llena rápidamente. ¿Qué datos se pueden limpiar?

Primero determine el origen: utilice df -h, du -xh /var/lib/docker | sort -h | tail y docker system df. A menudo crecen los Docker container logs, las imágenes antiguas y los archivos de copias de seguridad que no se eliminaron después de enviarse al almacenamiento externo. No elimine los volúmenes de PostgreSQL ni los datos de MeshCentral con el comando docker system prune --volumes sin comprender exactamente las consecuencias. Configure la rotación de registros y la retención del historial de alertas.

¿Qué configuración mínima de VPS será adecuada?

Para un entorno de prueba de hasta 20 dispositivos, son adecuados 2 vCPU, 4 GB de RAM y 60 GB de NVMe. Para un uso práctico con varias decenas de dispositivos, es mejor comenzar con 4 vCPU, 8 GB de RAM y 100–120 GB de NVMe. Son importantes una IP estática estable, los puertos 80 y 443 abiertos, unos IOPS de disco normales y la posibilidad de almacenar las copias de seguridad fuera del servidor principal. No cuente con 1 GB de RAM.

¿Qué elegir: VPS o dedicated para esta tarea?

Un VPS es adecuado para la mayoría de las instalaciones pequeñas de hasta 100–150 dispositivos, siempre que tenga recursos garantizados, disco NVMe y una red estable. Conviene elegir un dedicated con cientos de agentes, una alta actividad de sesiones remotas, largos periodos de retención de registros, requisitos de aislamiento o la necesidad de ejecutar servicios adicionales junto a él. Comience con un VPS y supervise la RAM, los IOPS, la carga de CPU y el crecimiento de la base de datos; la migración a un servidor dedicado solo será necesaria cuando se confirme la carga.

¿Se puede abrir el panel únicamente a través de una VPN?

Sí, y es una buena opción para la interfaz administrativa. Puede limitar el acceso a rmm.example.com mediante las direcciones IP de la red WireGuard o reglas de Caddy/firewall, manteniendo la API y MeshCentral disponibles para los agentes mediante HTTPS. Sin embargo, separe cuidadosamente las rutas y los dominios: si cierra completamente la API a Internet, los dispositivos detrás de NAT dejarán de conectarse. Antes de modificar las reglas, pruebe el acceso desde un agente de prueba fuera de su red local.

¿Por qué algunos agentes dejaron de conectarse después de la actualización?

Compruebe las release notes de la versión instalada, los registros de la API, la validez del certificado TLS y los cambios en los nombres de dominio. Si el reverse proxy cambió durante la actualización, es posible que no se estén reenviando las conexiones WebSocket necesarias para MeshCentral. Asegúrese también de que la hora del VPS sea correcta y de que la base de datos haya completado correctamente las migraciones. Ante un fallo grave, restaure una copia de seguridad verificada o revierta las imágenes únicamente mediante el procedimiento documentado, sin mezclar versiones de la base de datos y de la aplicación.

Conclusiones y próximos pasos

Ahora dispone de su propia instalación de Tactical RMM en un VPS: un servidor protegido, dominios HTTPS, una plataforma de contenedores, un panel de gestión de agentes y un esquema de copias de seguridad. Este sistema permite mantener estaciones de trabajo y servidores de forma centralizada sin depender de un servicio RMM en la nube.

1. Añada un equipo Windows de prueba y un servidor Linux, y compruebe las alertas, los comandos remotos y el acceso mediante MeshCentral.
2. Cree una biblioteca de scripts seguros: comprobación de espacio, limpieza de archivos temporales, actualización de paquetes, reinicio de servicios e inventario.
3. Configure MFA, los roles de los operadores, las notificaciones externas y una prueba periódica de recuperación de la copia de seguridad.

A medida que aumente el número de dispositivos, revise los intervalos de comprobación, el espacio en disco, el periodo de retención del historial y la RAM disponible. Primero automatice las acciones repetitivas y, después, si es necesario, traslade las copias de seguridad, la monitorización y los componentes independientes a una infraestructura separada.