A escolha entre broker MQTT auto-hospedado e gerenciado define quanto da sua semana vai para infraestrutura em vez de trabalho no produto. Este artigo compara as duas opções em esforço operacional, custos ocultos e responsabilidade de segurança e, em seguida, oferece uma matriz de decisão para que você escolha com segurança o modelo certo para o seu projeto.
Se precisar relembrar o que um broker MQTT faz antes de comparar os modelos de hospedagem, comece por lá.
O que "auto-hospedado" e "gerenciado" realmente significam
Um broker auto-hospedado é um software que você instala e opera: Mosquitto, EMQX, VerneMQ, NanoMQ ou outro broker open source ou comercial rodando em uma VM, um Raspberry Pi, um cluster Kubernetes ou um servidor na sua fábrica. Você é dono do sistema operacional, da configuração do broker, dos certificados TLS, da base de usuários, dos backups e do pager.
Um broker MQTT gerenciado é um serviço. O provedor roda o broker, mantém os patches em dia, renova os certificados e expõe os endpoints; você recebe um hostname, portas e credenciais. Você continua dono do design dos topics, do código dos clientes e dos dados, mas não dos servidores por baixo. Um broker MQTT gerenciado, totalmente operado pelo provedor, como a ConnectMQ, entrega um broker pronto em poucos minutos.
Entre os dois existe um modelo híbrido: bring your own cloud (BYOC), em que o broker roda na sua conta de nuvem, mas o fornecedor o opera. Esse modelo é abordado no guia de broker MQTT BYOC.
O trabalho real de rodar o seu próprio broker
Instalar o Mosquitto leva um minuto. Operá-lo bem exige esforço contínuo. Uma configuração auto-hospedada pronta para produção normalmente precisa de:
# Minimal production mosquitto.conf - every line is something you now maintain
per_listener_settings true
listener 8883
certfile /etc/mosquitto/certs/fullchain.pem
keyfile /etc/mosquitto/certs/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl
listener 8084
protocol websockets
certfile /etc/mosquitto/certs/fullchain.pem
keyfile /etc/mosquitto/certs/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
persistence true
persistence_location /var/lib/mosquitto/
max_queued_messages 1000
message_size_limit 1048576
Esse arquivo é só o começo. Em volta dele você precisa de:
- Ciclo de vida dos certificados - obter certificados, renová-los antes do vencimento e recarregar o broker sem derrubar clientes.
- Patches do SO e do broker - acompanhar alertas de segurança do kernel, do OpenSSL e do próprio broker.
- Gestão de usuários e credenciais - criar, rotacionar e revogar credenciais de dispositivos, de preferência sem editar arquivos à mão.
- Monitoramento - acompanhar contagem de conexões, taxas de mensagens, memória e disco, e alertar uma pessoa quando algo sair do normal.
- Proteção contra abuso - limites de taxa, limites de conexão e bloqueio de tentativas de login por força bruta.
- Backups e recuperação - arquivos de persistência, configuração e a base de senhas.
- Planejamento de capacidade - saber quando um único nó deixou de ser suficiente e o que fazer a respeito.
- Plantão - alguém que atenda quando o broker parar às 3 da manhã.
Nenhuma dessas tarefas é difícil isoladamente. Juntas, viram um trabalho de meio período que raramente aparece na estimativa original.
Broker MQTT auto-hospedado vs. gerenciado: lado a lado
| Fator | Auto-hospedado | Gerenciado |
|---|---|---|
| Tempo até a primeira conexão | Horas a dias (servidor, TLS, autenticação) | Minutos (cadastro, criação do broker) |
| Custo de infraestrutura | Servidor ou VM, armazenamento, banda | Mensalidade do plano ou camada gratuita |
| Custo de pessoas | Operação contínua, patches, plantão | Em grande parte absorvido pelo provedor |
| Certificados TLS | Você emite e renova | Fornecidos e renovados |
| Hardening de segurança | Sua responsabilidade de ponta a ponta | Compartilhada: o provedor faz o hardening, você protege as credenciais |
| Personalização | Controle total do broker e dos plugins | Limitada ao que o serviço expõe |
| Localização de rede | Qualquer lugar, inclusive sites isolados (air-gapped) | Endpoint na internet (ou na sua nuvem com BYOC) |
| Escalabilidade | Você projeta e opera | Troca de plano ou camada |
| Controle dos dados | Totalmente no seu hardware | Depende do provedor e do modelo de implantação |
Nenhuma coluna vence em tudo. A questão é qual das fraquezas de cada coluna prejudica menos o seu projeto.
Custos ocultos que a maioria das equipes ignora
O custo visível da auto-hospedagem é a fatura da VM. Os custos ocultos costumam ser maiores:
- Tempo dos engenheiros. Cada hora gasta renovando certificados, depurando um disco cheio ou atualizando um broker é uma hora a menos no firmware dos dispositivos ou na sua aplicação.
- Custo de incidentes. Uma queda do broker para todos os dispositivos de uma vez. O custo é o tempo parado mais a correria para diagnosticar um sistema pouco familiar sob pressão.
- Dívida de segurança. Um listener de teste esquecido na porta 1883 com
allow_anonymous trueé uma forma comum de brokers acabarem expostos na internet. - Concentração de conhecimento. Muitas vezes só uma pessoa sabe como o broker está configurado. Quando ela sai, o conhecimento vai junto.
Para uma forma estruturada de colocar números nesses itens, veja o artigo sobre custo total de propriedade de um broker MQTT. Use os seus próprios números de salários e incidentes; valores genéricos raramente batem com a realidade.
Responsabilidades de segurança: quem cuida de quê
A segurança é compartilhada nos dois modelos, mas a divisão é diferente.
Com um broker auto-hospedado, tudo é seu: regras de firewall, configuração de TLS, escolha de cifras, hashing de senhas, arquivos de ACL, hardening do SO, retenção de logs e resposta a intrusões.
Com um broker MQTT gerenciado, o provedor cuida da camada de plataforma. Na ConnectMQ, por exemplo, a plataforma oferece TLS na porta 8883 e Secure WebSocket na 8084 com certificado Let's Encrypt, isolamento multi-tenant, cotas por plano, proteção contra flood, bloqueio de IP após tentativas de login malsucedidas repetidas e client IDs vinculados às credenciais que ela emite. Você continua responsável por:
- Manter usuários e senhas fora de repositórios públicos e de dumps de firmware.
- Usar TLS (8883 ou 8084) nos dispositivos em vez da porta 1883 sem criptografia em produção.
- Projetar os topics para que dados sensíveis não sejam publicados onde não deveriam.
O guia de boas práticas de segurança MQTT aborda o lado do cliente em detalhes.
Quando a auto-hospedagem é a decisão certa
A auto-hospedagem é uma boa escolha quando:
- A rede é isolada. Uma fábrica air-gapped, uma mina subterrânea ou uma plataforma offshore sem conectividade confiável precisa de um broker local.
- Você precisa de recursos do broker que um serviço não expõe, como um plugin de autenticação personalizado ou uma configuração de bridge específica.
- Você já tem uma equipe de plataforma madura com monitoramento, patches e plantão estabelecidos, de modo que mais um serviço acrescenta pouco esforço marginal.
- A regulamentação exige processamento on-premises e uma implantação operada pelo fornecedor no seu ambiente não é uma opção.
Mesmo nesses casos, muitas equipes combinam um broker de borda local com um broker na nuvem para acesso remoto, usando uma bridge MQTT ou uma aplicação gateway.
Quando um broker MQTT gerenciado é a melhor escolha
Um broker MQTT gerenciado costuma vencer quando:
- Sua equipe é pequena e ninguém quer ficar de plantão por infraestrutura.
- Você está prototipando ou lançando e a velocidade até o primeiro dispositivo funcionando importa mais do que uma personalização profunda.
- Os dispositivos estão espalhados pela internet - casas, veículos, fazendas, estações de saneamento e outros locais remotos - e precisam de um endpoint público estável com TLS.
- Sua carga cresce em degraus. Passar de uma camada gratuita para uma paga ou para um cluster dedicado é mais simples do que redesenhar um servidor.
A ConnectMQ cobre esses degraus com um plano Serverless gratuito (até 25 conexões, QoS até 1, mensagens de 256 KB), um plano Serverless pago (até 1.000 conexões, QoS 2, mensagens de 1 MB, shared subscriptions), clusters isolados Dedicated, BYOC e uma opção Self Managed Enterprise.
Uma matriz de decisão que você pode usar hoje
Dê de 0 a 2 pontos para cada linha conforme o seu projeto e depois some cada coluna.
| Pergunta | Pontos para auto-hospedado | Pontos para gerenciado |
|---|---|---|
| O broker precisa funcionar sem acesso à internet? | 2 se sim | 0 |
| Você já tem uma equipe de operações com plantão? | 2 se sim | 2 se não |
| Você precisa de plugins personalizados no broker? | 2 se sim | 0 |
| O time to market é crítico? | 0 | 2 se sim |
| Os dispositivos estão espalhados pela internet pública? | 0 | 2 se sim |
| Menos de duas pessoas vão manter o sistema? | 0 | 2 se sim |
| Um gasto mensal previsível importa mais do que o menor custo bruto de servidor? | 0 | 2 se sim |
Se a coluna de gerenciado somar mais, comece com um broker MQTT gerenciado e mantenha os seus clientes no padrão para poder migrar depois, se as necessidades mudarem. O artigo sobre vendor lock-in em MQTT explica como manter a portabilidade.
Teste o modelo gerenciado em cinco minutos
Você sente a diferença na hora. Com os clientes de linha de comando do Mosquitto instalados, assine e publique no servidor MQTT público (gratuito, apenas para testes e protótipos, nunca para dados de produção):
# Terminal 1: assinar (use o seu próprio prefixo único)
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-7f3a9 -t "connectmq/demo/7f3a9/#" -v
# Terminal 2: publicar
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-7f3a9 -t "connectmq/demo/7f3a9/temp" -m "21.4"
Depois faça o mesmo no seu próprio broker privado via TLS, usando as credenciais geradas no portal:
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-V mqttv5 -t "plant1/line1/temp" -m "21.4"
Nenhum certificado para emitir, nenhum arquivo de configuração para editar. Compare isso com o checklist anterior e você terá o cerne da decisão.
Comece com um broker MQTT gerenciado
Se a matriz apontar para o gerenciado, experimente a ConnectMQ com dispositivos reais antes de se comprometer. Crie um broker Serverless gratuito sem cartão de crédito, conecte um dispositivo via TLS e use o cliente MQTT no navegador e o explorador de topics ao vivo para ver as suas mensagens chegando. Para o panorama completo das opções de hospedagem, leia o guia de broker MQTT na nuvem.
Perguntas frequentes
Um broker MQTT auto-hospedado é mais barato que um gerenciado?
O servidor em si costuma ser mais barato, mas o custo total inclui patches, certificados, monitoramento e tempo de plantão. Para equipes pequenas, o custo de pessoas normalmente supera a economia com o servidor.
Posso começar com um gerenciado e migrar para auto-hospedado depois?
Sim, se os seus clientes usarem MQTT 3.1.1 ou 5.0 padrão e você evitar recursos específicos do provedor. Trocar de broker passa a significar apenas atualizar host, porta e credenciais.
Perco o controle dos meus dados com um broker MQTT gerenciado?
Você mantém o controle do que publica e de quem tem credenciais. Se precisar do broker dentro da sua própria conta de nuvem, uma implantação BYOC mantém a infraestrutura lá enquanto o fornecedor a opera.
E os brokers em redes isoladas (air-gapped)?
Uma rede isolada precisa de um broker local. Um padrão comum é um broker de borda local para a fábrica mais um broker MQTT gerenciado na nuvem para dashboards remotos, conectados por uma bridge ou gateway.
