Free MQTT Brokers for Testing: Which One to Use

The right free MQTT broker for testing depends on what you are testing. For a first "does my code connect?" check, a shared endpoint like broker.connectmq.com or a public sandbox works in seconds with no sign-up. For automated tests, run a broker locally or in CI. For anything involving credentials, ACLs or realistic load, use a private broker — free tiers exist, and a private managed instance is the step after that.

This guide groups the options by type, says what each is good and bad at, and gives you a one-minute check for each.

Four kinds of free test brokers

None of them is "the best". A typical project uses two or three: a shared endpoint while writing the first lines of code, a local broker in CI, and a private broker before going live.

1. Shared endpoints and public sandboxes

These need nothing but a hostname. They are the fastest way to answer "is my client code right?".

ConnectMQ shared endpoint

broker.connectmq.com is the shared endpoint of ConnectMQ, a managed MQTT broker, intended for quick tests. It speaks MQTT 3.1.1 and MQTT 5 on the usual ports:

Because it is the same service that runs private instances, code you test here — including TLS and WebSocket settings — is the code you later point at your own broker with only the hostname and credentials changed.

Community public brokers

• test.mosquitto.org — run by the Eclipse Mosquitto project. It offers plain, TLS and WebSocket ports, plus ports for testing client certificates and authentication; the site lists them all. It is explicitly a test server and can be slow or restarted.
• broker.hivemq.com — HiveMQ's public broker, with TCP on 1883 and WebSockets. Handy for browser demos.
• broker.emqx.io — EMQX's public broker, with TCP, TLS, WebSocket and secure WebSocket ports.

All of them are shared and anonymous: every user can read what you publish if they guess or wildcard-subscribe to your topic. Availability and limits are up to the operators and can change without notice. For a side-by-side look at how they behave, see public MQTT brokers compared.

One-minute check

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'

If the subscriber prints testmqtt/free-test/hello it works, your network path, port and client tools are fine. Swap the hostname to try any other public broker. No terminal handy? Use the online MQTT client — it connects over secure WebSockets straight from the browser.

Test a free broker in your browser

2. Free tiers of managed services

Several managed MQTT services offer a free plan or free quota: you sign up and get a private broker with your own credentials and TLS. HiveMQ Cloud and EMQX Serverless are well-known examples; others exist, and the details (connection caps, message quotas, whether a card is required) vary by provider and change over time, so read the current terms on the provider's site.

Free tiers are good for:

• testing username/password authentication and per-topic permissions,
• testing TLS with a real certificate chain,
• a small prototype or a home project with a few devices.

They are less suited to load tests (quotas run out quickly) and to anything where you need guarantees. When the prototype becomes a product, the usual next step is a paid plan or a private instance on the same service, which keeps the client configuration identical.

3. Local brokers in Docker or CI

For automated tests, a broker you start yourself beats any hosted option: it is isolated, has no quotas, works offline and is torn down after the run.

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

Mosquitto 2 only listens on localhost and rejects anonymous clients unless you configure a listener, which is why the two-line config is needed. Generate a fuller one with the mosquitto.conf generator, or start the broker from your test code with Testcontainers.

Local brokers have one blind spot: they do not show what happens over a real internet path — NAT timeouts, TLS from a device, proxies in a corporate network. Pair them with at least one test against a remote broker.

Which one should you use?

If the question is really "public or private?", public vs private MQTT brokers goes deeper, and the broker directory lists hosted and self-hosted options with their protocols and ports.

Mistakes to avoid

• Generic topics. test/topic on a public broker will show you strangers' messages and confuse your test. Always use a unique prefix.
• Fixed client IDs. If two developers run the same example with client_id="test", the broker disconnects one when the other connects. Use the client ID generator or add a random suffix.
• Assuming retained state. Other users can overwrite or clear retained messages on shared brokers. Do not rely on them between test runs.
• Benchmarking a sandbox. Results reflect everyone else's traffic, and heavy runs may get you rate-limited or blocked.
• Shipping with the test host. Put the broker URL in configuration, not code, so switching from the test broker to production is a config change.

Free brokers make the first hour of MQTT development frictionless. Use a shared endpoint or public sandbox to prove your code works, a local broker to keep tests fast and reliable, and a private broker as soon as credentials, permissions or real traffic enter the picture.

Frequently asked questions