Como funciona o Tactical RMM
O Tactical RMM funciona com dois lados que conversam em tempo real: um servidor que concentra o painel e a lógica (Django, Vue, PostgreSQL, Redis, Celery, NATS e MeshCentral, atrás de um Nginx) e um agente leve em Go instalado em cada máquina monitorada. A ligação entre eles é a mensageria NATS: quando você dispara uma verificação ou um script no painel, a ordem chega ao endpoint pelo NATS, o agente executa localmente e devolve o resultado pela mesma via.
Abaixo você encontra a arquitetura por componente, as portas envolvidas, o passo a passo de como o agente roda um script, o que acontece quando a máquina fica offline e os requisitos de rede. Se ainda está na dúvida sobre o produto em si, comece por o que é o Tactical RMM.
A arquitetura do Tactical RMM, componente a componente
Servidor (Django + Vue)
O backend roda em Django sob uWSGI e expõe a API; o painel é uma aplicação Vue servida pelo Nginx. É onde você cadastra clientes, configura verificações, dispara scripts e enxerga o estado de cada máquina.
Agente (Go) no endpoint
Em cada computador monitorado roda um agente leve escrito em Go, sob o contexto SYSTEM no Windows. Ele executa as verificações localmente, recebe scripts do servidor e devolve o resultado.
Mensageria NATS
A conversa em tempo real entre agente e servidor passa pelo NATS, nas portas 4222 (TCP) e 9235 (WebSocket sobre TLS). É por ele que uma ordem de script chega ao endpoint no instante em que a máquina está online.
MeshCentral pra acesso remoto
O controle de tela e o navegador de arquivos vêm da integração com o MeshCentral, que escuta na porta 4430 e é exposto pelo Nginx via 443. É o que entrega suporte remoto sem instalar um segundo agente.
Fila Celery, Redis e PostgreSQL
Tarefas agendadas e processamento assíncrono passam por Celery e Celery Beat, com Redis como broker e cache. Todo o estado persistente (clientes, máquinas, históricos) fica no PostgreSQL.
Nginx e três subdomínios
O Nginx atua como proxy reverso na frente de tudo. A operação usa três nomes de host (painel, API e mesh), cada um respondendo em HTTPS na porta 443.
Os dois lados: servidor e agente
No servidor mora o cérebro da operação. O Django (rodando sob uWSGI) atende a API, o painel Vue é entregue pelo Nginx, e um conjunto de serviços de apoio cuida do resto: Daphne para WebSocket, Celery e Celery Beat para tarefas agendadas, Redis como broker e cache, e o PostgreSQL guardando todo o estado. O MeshCentral roda ao lado, como serviço próprio, dedicado ao acesso remoto.
No endpoint mora o agente em Go. Ele é deliberadamente enxuto: não carrega interface, roda sob o contexto SYSTEM no Windows (o que lhe dá permissão para administrar a máquina) e mantém uma conexão de saída com o servidor. Toda a inteligência de quando e o que executar vem do servidor; o agente é o braço que realiza no endpoint.
A mensageria NATS em tempo real (portas 4222 e 9235)
O que torna o Tactical RMM ágil é o NATS, um barramento de mensageria de baixa latência que substitui o velho modelo de o agente ficar perguntando ao servidor a cada tantos minutos. Com o NATS, assim que a máquina está online, uma ordem cai no endpoint quase instantaneamente. A camada usa a porta 4222 (TCP) para o tráfego principal e a 9235 para a conexão WebSocket sobre TLS.
Esse é o canal por onde trafegam verificações, scripts, comandos de terminal e mudanças de configuração. Quando você altera uma política no painel, a alteração é empurrada pelo NATS para os agentes online naquele momento, sem espera por um próximo ciclo.
MeshCentral para acesso remoto (porta 4430)
O controle remoto não é reinventado pelo Tactical RMM: ele integra o MeshCentral, um projeto maduro de acesso remoto. O MeshCentral escuta internamente na porta 4430 e é publicado pelo Nginx via 443. Na prática, do painel você abre controle de tela, terminal e navegador de arquivos como se fossem nativos. O terminal e o navegador de arquivos passam pelo Nginx até o MeshCentral local, enquanto o controle de tela (take control) e o status do agente trafegam pela via do NATS. O resultado é suporte remoto a Windows, Linux e macOS sem precisar instalar um segundo agente.
A fila de tarefas: Celery, Redis e PostgreSQL
Nem tudo precisa acontecer em tempo real. Verificações agendadas, relatórios, sincronizações e tarefas pesadas passam por uma fila assíncrona. O Celery Beat decide quando algo deve rodar, o Celery executa o trabalho em segundo plano e o Redis serve de broker e cache entre os dois. O resultado e o histórico ficam gravados no PostgreSQL, a fonte da verdade da plataforma.
Essa separação entre o tempo real (NATS) e o assíncrono (Celery) é o que permite ao servidor atender muitos agentes sem travar: o que é urgente vai pelo barramento de mensageria, o que é programado vai pela fila.
Como o agente executa um script, passo a passo
Quando uma verificação ou um script dispara, o ciclo é objetivo e não deixa rastro residente na máquina:
1. Transferência
O servidor envia o conteúdo do script para o agente pela mensageria NATS.
2. Gravação temporária
O agente salva o script em um arquivo de nome aleatório dentro de C:\ProgramData\TacticalRMM.
3. Execução como SYSTEM
O arquivo é executado sob o contexto SYSTEM, com permissão administrativa sobre o endpoint.
4. Retorno do resultado
A saída e o código de retorno são capturados e devolvidos ao servidor pelo NATS.
5. Limpeza automática
O arquivo temporário é removido ao fim da execução ou quando estoura o timeout.
O que acontece quando a máquina está offline
Se o endpoint está desligado ou sem rede, nada se perde. O servidor mantém as tarefas em fila e o agente faz check-in periódico. No instante em que reconecta, ele recebe e executa o que ficou pendente, e qualquer mudança de configuração feita nesse intervalo é propagada na mesma reconexão. Por isso uma máquina que passou o fim de semana fora aplica, ao voltar, o que foi definido enquanto estava ausente.
Requisitos de rede: só saída na 443
Do ponto de vista do cliente, o requisito é simples e seguro: o agente só precisa de conexões de saída (outbound) na porta 443 para os três subdomínios da operação (o do painel, o da API e o do mesh). Não é necessário abrir portas de entrada no firewall, fazer redirecionamento (NAT) nem expor a máquina à internet. Isso reduz a superfície de ataque: o endpoint inicia a conversa, nunca o contrário.
Para instalar e dimensionar o servidor, ver versões de sistema suportadas e checar o que cada endpoint precisa, veja o guia de requisitos e instalação do Tactical RMM.
Perguntas frequentes
Quer o Tactical RMM rodando sem montar essa arquitetura?
A UNODATA entrega o Tactical RMM gerenciado, com servidor, certificados, NATS, MeshCentral e backup já configurados, ambiente pronto em até 48 horas e suporte em português. Você foca em atender os endpoints; a infraestrutura é com a gente.
Conhecer o Tactical RMM da UNODATA