Public MQTT Brokers vs Private Brokers: When to Switch

Almost every MQTT project starts on a public broker. You copy broker.hivemq.com or broker.emqx.io from a tutorial, connect without credentials, and messages flow in seconds. That speed is exactly why public brokers exist. But the same openness that makes them easy also makes them unsuitable for anything beyond experiments. This guide lays out the trade-offs honestly so you know when to stay and when to move.

What a public MQTT broker actually is

A public broker is a shared MQTT server that accepts anonymous connections from anyone on the internet. Vendors and open-source projects run them as demos and interoperability sandboxes. Our public broker list covers the popular ones. Their defining properties:

• No sign-up and usually no username or password.
• One shared topic namespace for every user in the world.
• Best-effort operation for testing, not a supported service.

The real risks of public sandboxes

1. Anyone can read and write your topics

With no authentication and no access control, a subscriber to # receives every message on the broker — including yours. Anyone can also publish to your command topics. If a device listens on home/garage/door/set, a stranger can open it. Obscure topic names reduce collisions, but they are not security: anyone subscribed to # sees them.

2. Retained junk and stale state

Retained messages persist until someone clears them. On a public broker, topics are littered with retained payloads from other users and old tests, and anyone can overwrite your retained state. A dashboard that trusts the retained value on subscribe can show data that was never yours. See MQTT retained messages for how retention works.

3. Topic and client ID collisions

Generic topics like test/temperature are shared with everyone who followed the same tutorial. Generic client IDs are worse: when someone else connects with your ID, the broker disconnects you, and both clients end up in a reconnect loop. Details in MQTT connection errors.

4. No SLA, no support, no notice

Public brokers can be restarted, upgraded or rate-limited at any time. Some run development builds on purpose. That is fine for a sandbox, but it means a demo can fail in front of a customer for reasons you cannot see or fix.

5. Rate limits and missing features

Operators protect shared infrastructure with connection, message-rate and payload limits, which may be undocumented. You also cannot test the features production depends on: authentication, per-topic permissions, client certificates, bridging or persistence settings.

When a public broker is perfectly fine

• Learning MQTT concepts such as QoS, wildcards and Last Will.
• Checking that a new client library or device firmware can connect and publish.
• Quick demos with dummy data and a randomized topic prefix.
• Reproducing a bug against a neutral, well-known broker.

If you do use one, keep a few habits:

# 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

Try a public broker safely

Signals that it is time to switch

1. Your messages contain anything you would not post publicly.
2. Devices accept commands over MQTT.
3. Someone other than you depends on it — a teammate, a pilot customer, a demo.
4. You need to test authentication, ACLs or TLS client certificates.
5. You have hit unexplained disconnects, throttling or stray messages.

Your options for a private broker

Self-hosting is a solid choice and gives full control; the cost is ongoing work — certificate renewals, OS patches, backups and alerting. A managed broker trades some control for not having to do that work.

A sensible path: public for learning, private for everything else

You do not have to choose once and forever. Many teams use a public sandbox for the first afternoon — confirming a library works and the topic design makes sense — and move to a private broker as soon as real devices or teammates are involved. From that point on, development, staging and production each get their own broker or their own credentials, so a test script can never publish into production topics by accident.

Keep the connection details (URL, username, password) in configuration or environment variables from day one. Then switching brokers is a deployment change rather than a code change, and you can point the same build at a public broker for a demo or a private one for a pilot.

What to look for in a private or managed broker

• Isolation: your own instance or namespace, not a shared topic tree.
• Authentication: at least username/password per client; ideally per-device credentials.
• Authorization: per-topic access control so a sensor can publish only to its own topics.
• Encryption: TLS on 8883 and secure WebSockets for browser apps. See MQTT ports.
• Protocol support: MQTT 3.1.1 and MQTT 5, so older devices and newer features coexist.
• Standard endpoints: plain host and port, so moving later only means changing configuration.
• Visibility: a way to see connected clients and why a connection was rejected.

Migrating is mostly configuration

Because MQTT is a standard protocol, moving from a public to a private broker rarely touches application logic:

// 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}`,
});

Take the move as a chance to clean up your topic hierarchy, too — a consistent structure makes access rules far easier to write. MQTT topics and wildcards covers naming patterns that scale, and you can check filters with the topic matcher.

Frequently asked questions