Brokers MQTT públicos vs privados: quando migrar

Quase todo projeto MQTT começa em um broker público. Você copia broker.hivemq.com ou broker.emqx.io de um tutorial, conecta sem credenciais e as mensagens fluem em segundos. Essa rapidez é exatamente o motivo de os brokers públicos existirem. Mas a mesma abertura que os torna fáceis também os torna inadequados para qualquer coisa além de experimentos. Este guia apresenta os prós e contras com honestidade para você saber quando ficar e quando migrar.

O que é, de fato, um broker MQTT público

Um broker público é um servidor MQTT compartilhado que aceita conexões anônimas de qualquer pessoa na internet. Fornecedores e projetos open source os mantêm como demonstrações e sandboxes de interoperabilidade. Nossa lista de brokers públicos cobre os mais populares. Suas características principais:

• Sem cadastro e, geralmente, sem usuário ou senha.
• Um único namespace de tópicos compartilhado por todos os usuários do mundo.
• Operação no modelo best-effort para testes, não um serviço com suporte.

Os riscos reais dos sandboxes públicos

1. Qualquer pessoa pode ler e escrever nos seus tópicos

Sem autenticação e sem controle de acesso, quem assina # recebe todas as mensagens do broker — inclusive as suas. Qualquer pessoa também pode publicar nos seus tópicos de comando. Se um dispositivo escuta em home/garage/door/set, um estranho pode abri-lo. Nomes de tópicos obscuros reduzem colisões, mas não são segurança: qualquer um que assine # os vê.

2. Lixo retido e estado desatualizado

Mensagens retidas persistem até que alguém as apague. Em um broker público, os tópicos estão cheios de payloads retidos de outros usuários e de testes antigos, e qualquer pessoa pode sobrescrever o seu estado retido. Um dashboard que confia no valor retido ao assinar pode mostrar dados que nunca foram seus. Veja mensagens retidas (retained) no MQTT para entender como a retenção funciona.

3. Colisões de tópico e de client ID

Tópicos genéricos como test/temperature são compartilhados com todo mundo que seguiu o mesmo tutorial. Client IDs genéricos são piores: quando outra pessoa se conecta com o seu ID, o broker desconecta você, e os dois clientes acabam em um loop de reconexão. Detalhes em erros de conexão MQTT.

4. Sem SLA, sem suporte, sem aviso

Brokers públicos podem ser reiniciados, atualizados ou ter limites de taxa aplicados a qualquer momento. Alguns rodam builds de desenvolvimento de propósito. Isso é aceitável para um sandbox, mas significa que uma demo pode falhar na frente de um cliente por motivos que você não consegue ver nem corrigir.

5. Limites de taxa e recursos ausentes

Os operadores protegem a infraestrutura compartilhada com limites de conexões, de taxa de mensagens e de tamanho de payload, que podem não estar documentados. Você também não consegue testar os recursos dos quais a produção depende: autenticação, permissões por tópico, certificados de cliente, bridging ou configurações de persistência.

Quando um broker público é perfeitamente adequado

• Aprender conceitos do MQTT como QoS, curingas e Last Will.
• Verificar se uma nova biblioteca cliente ou firmware de dispositivo consegue conectar e publicar.
• Demos rápidas com dados fictícios e um prefixo de tópico aleatório.
• Reproduzir um bug em um broker neutro e conhecido.

Se você usar um, mantenha alguns hábitos:

# Random prefix + random client ID = fewer collisions
PREFIX="testmqtt/$(openssl rand -hex 4)"
mosquitto_sub -h broker.emqx.io -i "sub-$(openssl rand -hex 4)" -t "$PREFIX/#" -v

Experimente um broker público com segurança

Sinais de que é hora de migrar

1. Suas mensagens contêm algo que você não publicaria abertamente.
2. Dispositivos aceitam comandos via MQTT.
3. Alguém além de você depende disso — um colega, um cliente piloto, uma demo.
4. Você precisa testar autenticação, ACLs ou certificados TLS de cliente.
5. Você está enfrentando desconexões inexplicáveis, throttling ou mensagens estranhas.

Suas opções de broker privado

Auto-hospedar é uma escolha sólida e dá controle total; o custo é trabalho contínuo — renovação de certificados, patches do sistema operacional, backups e alertas. Um broker gerenciado troca um pouco de controle por não ter que fazer esse trabalho.

Um caminho sensato: público para aprender, privado para todo o resto

Você não precisa escolher uma vez e para sempre. Muitas equipes usam um sandbox público na primeira tarde — confirmando que a biblioteca funciona e que o design dos tópicos faz sentido — e migram para um broker privado assim que dispositivos reais ou colegas entram em cena. A partir daí, desenvolvimento, staging e produção ganham cada um seu próprio broker ou suas próprias credenciais, para que um script de teste nunca publique em tópicos de produção por acidente.

Mantenha os dados de conexão (URL, usuário, senha) em configuração ou variáveis de ambiente desde o primeiro dia. Assim, trocar de broker é uma mudança de deploy e não de código, e você pode apontar o mesmo build para um broker público em uma demo ou para um privado em um piloto.

O que procurar em um broker privado ou gerenciado

• Isolamento: sua própria instância ou namespace, não uma árvore de tópicos compartilhada.
• Autenticação: no mínimo usuário/senha por cliente; idealmente credenciais por dispositivo.
• Autorização: controle de acesso por tópico para que um sensor só publique nos seus próprios tópicos.
• Criptografia: TLS na 8883 e WebSockets seguros para aplicações no navegador. Veja portas MQTT.
• Suporte ao protocolo: MQTT 3.1.1 e MQTT 5, para que dispositivos antigos e recursos novos convivam.
• Endpoints padrão: host e porta simples, para que migrar depois signifique apenas mudar a configuração.
• Visibilidade: uma forma de ver os clientes conectados e por que uma conexão foi rejeitada.

Migrar é, na maior parte, configuração

Como o MQTT é um protocolo padrão, migrar de um broker público para um privado raramente afeta a lógica da aplicação:

// Before: public sandbox
mqtt.connect('wss://broker.emqx.io:8084/mqtt');

// After: private broker with credentials over TLS
mqtt.connect(process.env.MQTT_URL, {
  username: process.env.MQTT_USERNAME,
  password: process.env.MQTT_PASSWORD,
  clientId: `sensor-${deviceSerial}`,
});

Aproveite a migração para organizar também sua hierarquia de tópicos — uma estrutura consistente torna as regras de acesso muito mais fáceis de escrever. Tópicos e curingas MQTT aborda padrões de nomes que escalam, e você pode verificar filtros com o testador de tópicos.

Perguntas frequentes