Mosquitto Cloud Alternative: Moving From Self-Hosted Mosquitto to Managed MQTT

A Mosquitto cloud alternative is what many teams start looking for once their first self-hosted Mosquitto server becomes something customers depend on. This article explains what you keep, what you gain and what you give up when moving from self-hosted Mosquitto to a managed MQTT 3.1.1/5.0 broker, and shows a bridge configuration that lets you migrate one site at a time.

Why Mosquitto Is So Popular

Eclipse Mosquitto earned its place. It is open source, lightweight, well documented and runs on almost anything, from a Raspberry Pi to a large VM. It supports MQTT 3.1.1 and 5.0, TLS, WebSockets, password files, ACL files and bridging. Its command-line tools, mosquitto_pub and mosquitto_sub, are the default way many engineers test any broker.

For a lab, a single home or a plant network that never touches the internet, Mosquitto is often all you need. The question of an alternative only comes up when the operational side starts to outweigh the convenience. For a broader look at the open-source field, see the open-source MQTT broker comparison.

Where Self-Hosted Mosquitto Gets Hard

The broker is rarely the problem. The work around it is:

• Exposing it to the internet safely. You need a public IP or DNS name, firewall rules, TLS certificates and their renewal, and confidence that no anonymous listener was left open.
• Managing users. mosquitto_passwd and a text ACL file work for ten devices. With hundreds, you need provisioning scripts and a way to revoke credentials quickly.
• Monitoring. You must collect $SYS statistics or logs, store them and alert someone when connections drop.
• Upgrades. Major version upgrades can change defaults. Mosquitto 2.0, for example, changed listener and anonymous-access defaults, which surprised many existing installations.
• Single-node design. Open-source Mosquitto runs as a single broker process. If that machine fails, every client disconnects until it is back.

None of this is a criticism of Mosquitto. It is simply the cost of operating any broker yourself, which is covered more fully in self-hosted vs managed MQTT broker.

What You Keep With a Managed Broker

Because a managed broker speaks the same standard protocol, almost everything you built carries over:

• Client code. Paho, MQTT.js, PubSubClient, Node-RED and Mosquitto's CLI tools all work unchanged apart from host, port and credentials.
• Topic structure. Your topic tree moves as-is.
• MQTT 5 features. On ConnectMQ, shared subscriptions (paid plans), retained messages, session expiry, topic aliases, message expiry, response topics and reason codes are available.
• Your tooling habits. You can keep using mosquitto_sub to debug.

What You Gain

• No server to run. TLS on 8883 and Secure WebSocket on 8084 with a Let's Encrypt certificate are ready on day one.
• Credentials from a portal instead of password files. Each broker gets a generated username, password and client ID.
• Built-in visibility. The ConnectMQ portal includes an in-browser MQTT client, a live topic explorer, a dashboard and threshold alert rules, so you can see traffic without installing extra tools.
• Protection you would otherwise build yourself, such as per-plan quotas, flood protection and IP blocking after repeated failed logins.
• Industrial extras if relevant: detection of ISA-95 / Unified Namespace topics and decoding of Sparkplug B payloads.

What You Give Up

Be honest about the trade-offs before migrating:

If per-topic ACLs or custom plugins are central to your design, keep Mosquitto at the edge and use the cloud broker for the parts that benefit from it.

Questions to Ask Your Team First

Before comparing providers, agree internally on a few points. Which devices must keep working when the internet link is down? Who currently owns the Mosquitto server, and what would they rather be doing? Which topics carry commands that change physical equipment, and who should be able to publish them? How many simultaneous connections do you expect in a year, not just today? The answers decide whether you need a pure cloud broker, a hybrid with a local edge broker, or a dedicated deployment, and they keep the evaluation focused on your requirements rather than on feature lists.

Evaluating a Mosquitto Cloud Alternative

Whichever provider you consider, check the following against its current documentation:

1. Protocol versions. Does it support both MQTT 3.1.1 and 5.0, including the MQTT 5 features you use?
2. Ports and transports. TLS on 8883, WebSocket and Secure WebSocket for browser apps.
3. QoS levels and message size limits on the plan you would actually buy.
4. Retained messages and session expiry behaviour.
5. Authentication model. Username and password, client certificates, or both.
6. Free tier. Can you test with real devices before paying?
7. Deployment models. Shared, dedicated, in your own cloud, or self-managed.
8. Exit path. Can you leave without rewriting device firmware? The MQTT vendor lock-in article explains what to watch for.

Migrating Gradually With a Mosquitto Bridge

You do not have to cut over everything at once. Mosquitto's bridge feature can forward selected topics from your existing server to a managed broker. Add this to your mosquitto.conf (Mosquitto 2.x):

# Bridge local Mosquitto to a ConnectMQ broker over TLS
connection connectmq-bridge
address broker.connectmq.com:8883
bridge_protocol_version mqttv50
bridge_capath /etc/ssl/certs
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
cleansession false
restart_timeout 10 60

# Forward plant telemetry to the cloud, receive commands back
topic plant1/+/+/telemetry out 1
topic plant1/+/+/cmd in 1

Restart Mosquitto and check the log for a successful bridge connection:

sudo systemctl restart mosquitto
sudo journalctl -u mosquitto -n 50 --no-pager

Then verify that data arrives in the cloud by subscribing with the broker credentials:

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID-debug \
  -t "plant1/#" -v

Note that the managed broker binds client IDs to issued credentials, so for a second simultaneous connection such as this debug session, use a client ID you have been issued for it, or use the in-browser client in the portal instead.

The bridge pattern lets dashboards and remote users move to the cloud broker while local devices keep talking to the Mosquitto instance they already know. Once you are confident, you can repoint devices directly at the managed broker. The full process is described in migrate Mosquitto to cloud MQTT.

Troubleshooting the Bridge

• Bridge connects then drops repeatedly. Another client is using the same client ID. Each connection needs its own ID.
• TLS handshake errors. Confirm bridge_capath points to the system CA store, or use bridge_cafile with a bundle that includes the Let's Encrypt chain.
• Messages not forwarded. Check the topic pattern and direction (out sends local to remote, in receives remote to local).
• QoS 2 rejected. Free Serverless plans support QoS up to 1, so bridge at QoS 1 or upgrade.

Try a Managed Broker Alongside Mosquitto

You can test the managed side without touching production. Create a free Serverless broker on ConnectMQ with no credit card, add the bridge block above to a test Mosquitto instance and watch your topics appear in the live topic explorer. To understand the options in more depth, read the cloud MQTT broker guide or learn what a managed MQTT broker takes off your plate. More about the platform is at connectmq.com.

Frequently Asked Questions

Is there a hosted version of Mosquitto?

Some vendors offer hosted or commercially supported Mosquitto. Alternatively, any standards-compliant managed MQTT broker works with Mosquitto clients and bridges, since the protocol is the same.

Will my Mosquitto clients work with a managed broker?

Yes. Clients that speak MQTT 3.1.1 or 5.0 only need a new host, port, credentials and client ID.

Can I keep Mosquitto at the edge and use the cloud too?

Yes. A bridge forwards selected topics from a local Mosquitto to the cloud broker, which is a common pattern for plants and sites with unreliable connectivity.

Do I lose ACLs when moving away from Mosquitto?

It depends on the provider. ConnectMQ isolates tenants and binds client IDs to credentials but does not offer per-topic ACLs, so keep Mosquitto at the edge if you rely on them.