Brokers MQTT gratuitos para testes: qual usar

O broker MQTT gratuito para testes certo depende do que você está testando. Para uma primeira verificação de "meu código conecta?", um endpoint compartilhado como broker.connectmq.com ou um sandbox público funciona em segundos e sem cadastro. Para testes automatizados, rode um broker localmente ou no CI. Para qualquer coisa que envolva credenciais, ACLs ou carga realista, use um broker privado — existem planos gratuitos, e uma instância gerenciada privada é o passo seguinte.

Este guia agrupa as opções por tipo, mostra no que cada uma é boa ou ruim e traz uma verificação de um minuto para cada caso.

Quatro tipos de broker de teste gratuito

Nenhum é "o melhor". Um projeto típico usa dois ou três: um endpoint compartilhado enquanto escreve as primeiras linhas, um broker local no CI e um broker privado antes de entrar em produção.

1. Endpoints compartilhados e sandboxes públicos

Eles só precisam de um hostname. São a forma mais rápida de responder "meu código de cliente está certo?".

Endpoint compartilhado do ConnectMQ

broker.connectmq.com é o endpoint compartilhado do ConnectMQ, um broker MQTT gerenciado, pensado para testes rápidos. Ele fala MQTT 3.1.1 e MQTT 5 nas portas de sempre:

Como é o mesmo serviço que roda as instâncias privadas, o código que você testa aqui — incluindo as configurações de TLS e WebSocket — é o mesmo que depois vai apontar para o seu próprio broker, mudando apenas o hostname e as credenciais.

Brokers públicos da comunidade

• test.mosquitto.org — mantido pelo projeto Eclipse Mosquitto. Oferece portas sem criptografia, TLS e WebSocket, além de portas para testar certificados de cliente e autenticação; o site lista todas. É explicitamente um servidor de testes e pode ficar lento ou ser reiniciado.
• broker.hivemq.com — o broker público da HiveMQ, com TCP na 1883 e WebSockets. Prático para demos no navegador.
• broker.emqx.io — o broker público da EMQX, com portas TCP, TLS, WebSocket e WebSocket seguro.

Todos são compartilhados e anônimos: qualquer usuário pode ler o que você publica se adivinhar seu topic ou assinar com um curinga. Disponibilidade e limites dependem dos operadores e podem mudar sem aviso. Para ver como eles se comportam lado a lado, confira a comparação de brokers MQTT públicos.

Verificação de um minuto

mosquitto_sub -h broker.connectmq.com -p 1883 -t 'testmqtt/free-test/#' -v

mosquitto_pub -h broker.connectmq.com -p 1883 -t 'testmqtt/free-test/hello' -m 'it works'

Se o assinante imprimir testmqtt/free-test/hello it works, seu caminho de rede, a porta e as ferramentas de cliente estão ok. Troque o hostname para testar qualquer outro broker público. Sem terminal por perto? Use o cliente MQTT online — ele conecta por WebSockets seguros direto do navegador.

Teste um broker gratuito no navegador

2. Planos gratuitos de serviços gerenciados

Vários serviços MQTT gerenciados oferecem um plano gratuito ou uma cota grátis: você se cadastra e recebe um broker privado com suas próprias credenciais e TLS. HiveMQ Cloud e EMQX Serverless são exemplos conhecidos; existem outros, e os detalhes (limite de conexões, cotas de mensagens, se exigem cartão) variam por provedor e mudam com o tempo, então leia os termos atuais no site de cada um.

Planos gratuitos são bons para:

• testar autenticação com usuário e senha e permissões por topic,
• testar TLS com uma cadeia de certificados real,
• um protótipo pequeno ou um projeto doméstico com poucos dispositivos.

Eles se encaixam pior em testes de carga (as cotas acabam rápido) e em qualquer cenário que exija garantias. Quando o protótipo vira produto, o passo comum é um plano pago ou uma instância privada no mesmo serviço, o que mantém a configuração do cliente idêntica.

3. Brokers locais no Docker ou no CI

Para testes automatizados, um broker que você mesmo inicia é melhor que qualquer opção hospedada: é isolado, não tem cotas, funciona offline e é descartado ao fim da execução.

cat > mosquitto.conf <<'EOF'
listener 1883
allow_anonymous true
EOF
docker run --rm -p 1883:1883 -v "$PWD/mosquitto.conf:/mosquitto/config/mosquitto.conf" eclipse-mosquitto:2

O Mosquitto 2 só escuta em localhost e rejeita clientes anônimos, a menos que você configure um listener — por isso a configuração de duas linhas é necessária. Gere uma mais completa com o gerador de mosquitto.conf ou inicie o broker a partir do seu código de teste com Testcontainers.

Brokers locais têm um ponto cego: não mostram o que acontece em um caminho real pela internet — timeouts de NAT, TLS a partir de um dispositivo, proxies em uma rede corporativa. Combine-os com pelo menos um teste contra um broker remoto.

Qual você deve usar?

Se a pergunta de fundo é "público ou privado?", brokers MQTT públicos vs privados se aprofunda no tema, e o diretório de brokers lista opções hospedadas e auto-hospedadas com seus protocolos e portas.

Erros a evitar

• Topics genéricos. test/topic em um broker público vai mostrar mensagens de desconhecidos e confundir seu teste. Use sempre um prefixo único.
• Client IDs fixos. Se dois desenvolvedores rodam o mesmo exemplo com client_id="test", o broker desconecta um quando o outro conecta. Use o gerador de client ID ou adicione um sufixo aleatório.
• Contar com estado retido. Outros usuários podem sobrescrever ou apagar mensagens retidas em brokers compartilhados. Não dependa delas entre execuções de teste.
• Fazer benchmark em um sandbox. Os resultados refletem o tráfego de todo mundo, e testes pesados podem fazer você ser limitado ou bloqueado.
• Ir para produção com o host de teste. Coloque a URL do broker na configuração, não no código, para que trocar o broker de teste pelo de produção seja apenas uma mudança de configuração.

Brokers gratuitos tiram o atrito da primeira hora de desenvolvimento com MQTT. Use um endpoint compartilhado ou um sandbox público para provar que seu código funciona, um broker local para manter os testes rápidos e confiáveis, e um broker privado assim que credenciais, permissões ou tráfego real entrarem em cena.

Perguntas frequentes