The self-hosted vs managed MQTT broker decision shapes how much of your week goes into infrastructure instead of product work. This article compares the two options on operational effort, hidden costs and security responsibility, then gives you a decision matrix so you can pick the right model for your project with confidence.
If you need a refresher on what an MQTT broker does before comparing hosting models, start there.
What "Self-Hosted" and "Managed" Actually Mean
A self-hosted broker is software you install and operate: Mosquitto, EMQX, VerneMQ, NanoMQ or another open-source or commercial broker running on a VM, a Raspberry Pi, a Kubernetes cluster or a server in your plant. You own the operating system, the broker configuration, the TLS certificates, the user database, the backups and the pager.
A managed broker is a service. The provider runs the broker, keeps it patched, renews certificates and exposes endpoints; you receive a hostname, ports and credentials. You still own your topic design, client code and data, but not the servers underneath. A fully managed MQTT service such as ConnectMQ hands you a ready broker in a few minutes.
Between the two sits a hybrid: bring your own cloud (BYOC), where the broker runs in your cloud account but the vendor operates it. That model is covered in the BYOC MQTT broker guide.
The Real Work of Running Your Own Broker
Installing Mosquitto takes a minute. Operating it well takes ongoing effort. A production-ready self-hosted setup typically needs:
# Minimal production mosquitto.conf - every line is something you now maintain
per_listener_settings true
listener 8883
certfile /etc/mosquitto/certs/fullchain.pem
keyfile /etc/mosquitto/certs/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl
listener 8084
protocol websockets
certfile /etc/mosquitto/certs/fullchain.pem
keyfile /etc/mosquitto/certs/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
persistence true
persistence_location /var/lib/mosquitto/
max_queued_messages 1000
message_size_limit 1048576
That file is only the start. Around it you need:
- Certificate lifecycle - obtain certificates, renew them before expiry and reload the broker without dropping clients.
- OS and broker patching - track security advisories for the kernel, OpenSSL and the broker itself.
- User and credential management - create, rotate and revoke device credentials, ideally without editing files by hand.
- Monitoring - watch connection counts, message rates, memory and disk, and alert a human when something drifts.
- Abuse protection - rate limits, connection limits and blocking of brute-force login attempts.
- Backups and recovery - persistence files, configuration and the password database.
- Capacity planning - knowing when one node is no longer enough, and what to do about it.
- On-call - someone who answers when the broker stops at 3 a.m.
None of these tasks is hard on its own. Together they become a part-time job that rarely appears in the original estimate.
Self-Hosted vs Managed MQTT Broker: Side-by-Side
| Factor | Self-hosted | Managed |
|---|---|---|
| Time to first connection | Hours to days (server, TLS, auth) | Minutes (sign up, create broker) |
| Infrastructure cost | Server or VM, storage, bandwidth | Plan fee or free tier |
| People cost | Ongoing ops, patching, on-call | Mostly absorbed by the provider |
| TLS certificates | You issue and renew | Provided and renewed |
| Security hardening | Your responsibility end to end | Shared: provider hardens, you protect credentials |
| Customisation | Full control of broker and plugins | Limited to what the service exposes |
| Network location | Anywhere, including air-gapped sites | Internet endpoint (or your cloud with BYOC) |
| Scaling | You design and operate it | Change plan or tier |
| Data control | Fully on your hardware | Depends on provider and deployment model |
Neither column wins everywhere. The question is which column's weaknesses hurt your project less.
Hidden Costs Most Teams Miss
The visible cost of self-hosting is a VM bill. The hidden costs are usually larger:
- Engineer time. Every hour spent renewing certificates, debugging a full disk or upgrading a broker is an hour not spent on your device firmware or application.
- Incident cost. A broker outage stops every device at once. The cost is downtime plus the scramble to diagnose an unfamiliar system under pressure.
- Security debt. A forgotten test listener on port 1883 with
allow_anonymous trueis a common way brokers end up exposed on the internet. - Knowledge concentration. Often one person knows how the broker is configured. When they leave, so does the knowledge.
For a structured way to put numbers on these, see the MQTT broker total cost of ownership article. Use your own salary and incident figures; generic numbers rarely match reality.
Security Responsibilities: Who Owns What
Security is shared in both models, but the split differs.
With a self-hosted broker you own everything: firewall rules, TLS configuration, cipher choices, password hashing, ACL files, OS hardening, log retention and intrusion response.
With a managed broker the provider owns the platform layer. On ConnectMQ, for example, the platform provides TLS on port 8883 and Secure WebSocket on 8084 with a Let's Encrypt certificate, multi-tenant isolation, per-plan quotas, flood protection, IP blocking after repeated failed logins, and client IDs bound to the credentials it issues. You still own:
- Keeping usernames and passwords out of public repositories and firmware dumps.
- Using TLS (8883 or 8084) from devices rather than plain 1883 in production.
- Designing topics so that sensitive data is not published where it should not be.
The MQTT security best practices guide covers the client side in detail.
When Self-Hosting Is the Right Call
Self-hosting is a good fit when:
- The network is isolated. An air-gapped plant or a vessel without reliable connectivity needs a local broker.
- You need broker features a service does not expose, such as a custom authentication plugin or a specific bridge configuration.
- You already run a mature platform team with monitoring, patching and on-call in place, so one more service adds little marginal effort.
- Regulation requires on-premises processing and a vendor-operated deployment in your environment is not an option.
Even in these cases, many teams combine a local edge broker with a cloud broker for remote access, using an MQTT bridge or a gateway application.
When a Managed Broker Is the Better Choice
A managed broker usually wins when:
- You are a small team and nobody wants to be on call for infrastructure.
- You are prototyping or launching and speed to the first working device matters more than deep customisation.
- Devices are spread across the internet - homes, vehicles, remote sites - and need a stable public endpoint with TLS.
- Your load grows in steps. Moving from a free tier to a paid tier or a dedicated cluster is simpler than re-architecting a server.
ConnectMQ covers these steps with a free Serverless plan (up to 25 connections, QoS up to 1, 256 KB messages), a paid Serverless plan (up to 1,000 connections, QoS 2, 1 MB messages, shared subscriptions), Dedicated isolated clusters, BYOC and a Self Managed Enterprise option.
A Decision Matrix You Can Use Today
Score each row from 0 to 2 for your project, then add up each column.
| Question | Points toward self-hosted | Points toward managed |
|---|---|---|
| Must the broker run without internet access? | 2 if yes | 0 |
| Do you have an ops team with on-call already? | 2 if yes | 2 if no |
| Do you need custom broker plugins? | 2 if yes | 0 |
| Is time to market critical? | 0 | 2 if yes |
| Are devices spread over the public internet? | 0 | 2 if yes |
| Will fewer than two people maintain the system? | 0 | 2 if yes |
| Is predictable monthly spend more important than lowest raw server cost? | 0 | 2 if yes |
If the managed column is higher, start with a managed broker and keep your clients standard so you can move later if needs change. The MQTT vendor lock-in article explains how to stay portable.
Test the Managed Model in Five Minutes
You can feel the difference immediately. With Mosquitto's command-line clients installed, subscribe and publish against the public test broker:
# Terminal 1: subscribe (use your own unique prefix)
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-7f3a9 -t "connectmq/demo/7f3a9/#" -v
# Terminal 2: publish
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-7f3a9 -t "connectmq/demo/7f3a9/temp" -m "21.4"
Then do the same against your own private broker over TLS, using the credentials generated in the portal:
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-V mqttv5 -t "plant1/line1/temp" -m "21.4"
No certificates to issue, no config files to edit. Compare that with the checklist earlier and you have the core of the decision.
Get Started with a Managed MQTT Broker
If the matrix points toward managed, try ConnectMQ on real devices before committing. Create a free Serverless broker with no credit card, connect a device over TLS, and use the in-browser MQTT client and live topic explorer to watch your messages arrive. For the wider picture of hosting options, read the cloud MQTT broker guide.
Frequently Asked Questions
Is a self-hosted MQTT broker cheaper than a managed one?
The server itself is often cheaper, but total cost includes patching, certificates, monitoring and on-call time. For small teams the people cost usually outweighs the server savings.
Can I start managed and move to self-hosted later?
Yes, if your clients use standard MQTT 3.1.1 or 5.0 and you avoid provider-specific features. Changing brokers then means updating host, port and credentials.
Do I lose control of my data with a managed broker?
You keep control of what you publish and who has credentials. If you need the broker inside your own cloud account, a BYOC deployment keeps the infrastructure there while the vendor operates it.
What about brokers in air-gapped networks?
An isolated network needs a local broker. A common pattern is a local edge broker for the plant plus a managed cloud broker for remote dashboards, connected by a bridge or gateway.
