Choosing a broker is not only a software decision. It determines who owns upgrades, certificates, identity integration, scaling, backups, incident response, and the knowledge needed to recover a messaging system under pressure.
A managed MQTT broker, sometimes described as a cloud MQTT broker, reduces platform work. A self-hosted MQTT broker gives the team direct control over topology and runtime. Neither is automatically cheaper or safer—the right answer depends on constraints and operational capability.
Compare ownership first
| Area | Managed MQTT | Self-hosted MQTT |
|---|---|---|
| Provisioning | Service creates and maintains runtime | Team builds hosts, network, storage, and automation |
| Upgrades | Provider plans and operates broker upgrades | Team tests, schedules, rolls out, and rolls back |
| Availability | Defined by the service plan and architecture | Defined by the topology the team builds |
| Security boundary | Shared responsibility with provider controls | Team owns the full runtime and host boundary |
| Observability | Product dashboards, logs, and exposed metrics | Team selects, integrates, and operates the stack |
| Scaling | Plan or policy driven | Capacity planning and cluster changes are internal |
| Cost shape | Predictable service fee plus usage | Infrastructure plus engineering and on-call time |
| Customization | Bounded by supported configuration | Deep runtime and plugin control |
The hidden line item in self-hosting is not the virtual machine. It is the ongoing ownership of a stateful, internet-facing system.
When managed MQTT is the stronger default
Managed MQTT is usually a good fit when:
- the team needs to ship device connectivity without building a broker platform;
- security updates and certificate operations should not depend on one specialist;
- environments must be created consistently;
- product engineers need logs, connection controls, and access policy in one workflow;
- demand is uncertain and capacity should change without a clustering project.
Confirm what the provider actually manages. “Hosted” can still leave backups, upgrades, or high availability to the customer.
When self-hosting is justified
Self-hosting can be the right decision when:
- data must remain in a facility or network the provider cannot enter;
- a required broker plugin or protocol extension is unavailable in managed offerings;
- deterministic offline operation is mandatory;
- the organization already runs stateful distributed systems and has 24/7 ownership;
- extreme, stable scale makes dedicated infrastructure economically meaningful.
These are concrete constraints. A general preference for control is not enough unless the team is prepared to exercise that control during incidents.
Security responsibility does not disappear
With a managed broker, the provider may secure the runtime, patch broker software, and expose identity controls. The customer still owns:
- device credential lifecycle;
- topic-level publish and subscribe policy;
- payload data classification;
- client TLS validation;
- application-side authorization;
- incident response for compromised devices.
With self-hosting, add operating system hardening, network exposure, certificate automation, upgrade policy, secrets storage, backup restoration, and cluster security to that list.
Use the MQTT security guide to evaluate both options against the same baseline.
Model total cost with engineering time
Build a cost model from:
broker infrastructure
+ network and storage
+ monitoring and logging
+ backup and recovery
+ engineering maintenance
+ on-call and incident cost
+ expected capacity headroom
Then compare the same workload, availability target, retention policy, and support expectation. A small self-hosted node and a production managed cluster are not equivalent units.
Convert engineering work into the same monthly unit as the service bill. For example, estimate the hours spent on upgrades, certificate rotation, observability, capacity reviews, backups, on-call, and incident recovery, then multiply by the team's fully loaded hourly cost. Add expected incident impact separately rather than pretending every month is failure-free.
Run the model for at least three demand levels. A self-hosted MQTT broker may look inexpensive at steady low traffic but become costly when high availability, regional failover, or a reconnect spike requires another topology. A managed MQTT service may cost more at baseline but remove work that the team would otherwise have to staff and rehearse.
Do not count engineering time as free because the people already work for the company. The relevant question is which product, security, or reliability work they will not complete while operating the broker.
Run a migration rehearsal before committing
Whether moving to managed or self-hosted:
- inventory MQTT versions, transports, authentication methods, ACLs, topics, QoS, and session settings;
- test representative clients against the target;
- reproduce retained messages, persistent sessions, and offline queues deliberately;
- load-test reconnect storms, not only steady-state throughput;
- define DNS, certificate, credential, and rollback plans;
- observe both old and new systems during a controlled cutover.
MQTT clients often make broker migration straightforward, but session state and authorization details can still create surprises.
A practical decision
Choose managed MQTT when broker operations are not a product differentiator and the service meets the required security, network, and regional constraints. Choose self-hosting when an explicit technical or regulatory requirement outweighs the operational burden—and fund it as a platform, not a side project.
Use this constraint checklist before making the final choice:
- Is on-premises or fully offline operation mandatory?
- Does the workload require an unsupported plugin, protocol extension, or network topology?
- Can the team staff upgrades, security response, backups, and recovery around the clock?
- Have both options been compared at the same availability and support level?
- Has the team rehearsed a reconnect storm, broker failure, and rollback?
- Would operating the broker create a durable product advantage?
If the first two answers are no and the last answer is also no, managed MQTT is usually the lower-risk default. If self-hosting remains necessary, make the ownership and service objectives explicit before deployment.
Review the managed MQTT features, pricing, and public MQTT broker for a disposable client test before evaluating a production instance.