MQTT broker hosting ranges from a single virtual server you configure yourself to a fully managed broker running inside your own cloud account. This comparison walks through the five common options, shows the real work each one involves, and ends with a checklist that helps you pick the right one for your project today without blocking where it needs to go tomorrow.
The Five Common MQTT Broker Hosting Options
- Self-hosted on a VPS or on-premises server, usually with Mosquitto.
- Self-hosted on Kubernetes, using an open-source broker in containers.
- Managed serverless, a shared multi-tenant broker you consume as a service.
- Managed dedicated, an isolated broker cluster operated by a provider.
- BYOC (bring your own cloud), a provider-operated broker running in your own cloud account.
A sixth variant, vendor software that you install and operate yourself under an enterprise license, sits between options 1 and 5.
Side-by-Side Comparison
| VPS with Mosquitto | Kubernetes | Managed serverless | Managed dedicated | BYOC | |
|---|---|---|---|---|---|
| Time to first connection | Quick for a single server | Longer; cluster setup needed | Minutes, self-service | Requires scoping with the provider | Requires scoping and cloud account preparation |
| Who patches and upgrades | You | You | Provider | Provider | Provider |
| Who manages TLS certificates | You | You | Provider | Provider | Provider |
| Isolation from other tenants | Full | Full | Logical, shared infrastructure | Full | Full |
| Infrastructure ownership | You | You | Provider | Provider | You |
| Scaling effort | Manual resizing | Manual, cluster-aware | Choose a plan | Sized with provider | Sized with provider |
| Required in-house skills | Linux, networking, TLS | Kubernetes, networking, TLS | MQTT clients | MQTT clients | Cloud account administration |
| Best fit | Labs, small single-site systems | Teams already running Kubernetes | Prototypes to mid-size fleets | Production fleets needing isolation | Strict data control or existing cloud estate |
Option 1: VPS or On-Premises with Mosquitto
Eclipse Mosquitto is lightweight, well documented and easy to start with. A minimal production-minded configuration with TLS and password authentication looks like this:
# /etc/mosquitto/conf.d/production.conf
per_listener_settings true
listener 8883
certfile /etc/letsencrypt/live/mqtt.example.com/fullchain.pem
keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
listener 8084
protocol websockets
certfile /etc/letsencrypt/live/mqtt.example.com/fullchain.pem
keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
sudo apt install -y mosquitto mosquitto-clients
sudo mosquitto_passwd -c /etc/mosquitto/passwd device01
sudo systemctl restart mosquitto
That gets you started. The ongoing work is what people underestimate: renewing certificates and reloading the broker, applying OS and broker security updates, monitoring disk and memory, raising file descriptor limits, managing backups of the password file, handling brute-force login attempts and planning what happens when the single server fails.
Pros: full control, low direct cost, works offline on a local network. Cons: you are the on-call team; a single server is a single point of failure; security is entirely your responsibility.
Option 2: Kubernetes
If your organization already runs Kubernetes, deploying a broker there feels natural. You get declarative configuration, rolling updates and integration with existing monitoring.
The catch is that MQTT is a stateful, long-lived-connection protocol, and Kubernetes is at its best with stateless request-response services. You need TCP load balancing rather than HTTP ingress, careful pod disruption budgets so rolling updates do not disconnect every client at once, persistent volumes if you want session persistence, and an understanding of how your chosen broker behaves when pods are rescheduled. Our MQTT broker on Kubernetes guide covers these details.
Pros: fits existing platform tooling, infrastructure as code, full control. Cons: significant operational expertise required; easy to create disruptive reconnect storms during routine operations.
Option 3: Managed Serverless
A serverless broker is the fastest way to a secure endpoint. You sign up, create a broker and receive a hostname, ports and credentials. The provider runs a shared, multi-tenant cluster and enforces per-plan quotas to keep tenants isolated.
ConnectMQ's Serverless plans are an example:
- Serverless (Free): up to 25 connections, QoS up to 1, 256 KB messages.
- Serverless (Paid): up to 1,000 connections, QoS 2, 1 MB messages, shared subscriptions.
Both support MQTT 3.1.1 and 5.0 over TCP 1883, TLS 8883, WebSocket 8083 and Secure WebSocket 8084 with path /mqtt, with a Let's Encrypt certificate already in place. Connecting is the same as any broker:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-t "acme/#" -v -V mqttv5
Pros: minutes to start, no servers, security defaults handled, portal tools included. Cons: shared infrastructure, fixed plan limits, less control over location and tuning.
Read more in serverless MQTT broker.
Option 4: Managed Dedicated
A dedicated deployment gives you an isolated broker cluster that no other customer uses, still operated by the provider. It suits production systems where you want predictable performance unaffected by other tenants, and where the workload has outgrown shared plan limits. You describe expected connections, message rates and payload sizes, and the deployment is sized accordingly.
Pros: isolation, provider-run operations, sized to your workload. Cons: higher cost than shared plans; setup takes longer than a self-service signup.
See dedicated MQTT broker for the details.
Option 5: BYOC
With bring your own cloud, the broker runs in your own cloud account, under your billing, network controls and security policies, while the provider deploys and operates it. This suits organizations with strict data control requirements or a large existing cloud estate where consumers already live.
Pros: your infrastructure and data path, provider-run operations, placement next to your other systems. Cons: you pay the cloud bill and must grant and govern provider access; more coordination at setup.
Our BYOC MQTT broker article explains the model and the account preparation it needs.
What None of the Options Change
Whichever hosting model you choose, some things stay with you:
- Device firmware, reconnect logic and local buffering.
- Topic namespace design.
- Payload formats and validation.
- Storing history and integrating with other systems, typically with a subscriber service, Node-RED or Telegraf connecting as an MQTT client.
- Choosing QoS levels per message type.
Because MQTT is a standard, moving between hosting models mostly means changing a hostname and credentials on your clients, provided you avoid proprietary extensions.
How to Choose: A Hosting Checklist
Answer these questions in order. The first one that clearly applies usually decides the hosting model.
- Is this a learning exercise or demo? Use the public MQTT test broker and skip hosting entirely.
- Must the broker run on a local network without internet? Self-host on premises, or consider a self-managed enterprise option.
- Must data stay inside cloud accounts you own? Choose BYOC.
- Do you need isolation from other tenants or sizing beyond shared plans? Choose a dedicated deployment.
- Do you already operate Kubernetes and want the broker on the same platform? Self-host on Kubernetes, accepting the operational load.
- Otherwise: start on managed serverless, and move up as connections and requirements grow.
Also weigh total cost, not just the monthly price. Engineering time for patching, certificate renewal, incident response and upgrades is real cost on self-hosted options. MQTT broker total cost of ownership and self-hosted vs managed MQTT broker go deeper on that comparison, and the cloud MQTT broker guide gives the full overview.
Where ConnectMQ Fits
ConnectMQ covers the managed side of this table: Serverless (Free and Paid) for fast starts and growing fleets, Dedicated for isolated clusters, BYOC for brokers in your own cloud account, and Self Managed Enterprise for organizations that need to operate it themselves. All of them speak the same standard MQTT, so you can start small and move along the spectrum without redesigning your devices.
Start Hosting Your MQTT Broker on ConnectMQ
Create a free Serverless broker at app.connectmq.com, no credit card required, and connect your first device in minutes. When you need isolation or control over where the broker runs, talk to the team about Dedicated or BYOC. If you want a broader introduction first, read about choosing a fully managed MQTT service.
Frequently Asked Questions
What is the cheapest way to host an MQTT broker?
A free managed plan or a small self-hosted Mosquitto server costs the least in direct spending. Self-hosting adds your own time for patching, certificates and monitoring, which often outweighs the server cost.
Can I host Mosquitto on a VPS for production?
Yes, with TLS, authentication, monitoring and a plan for updates and failures. Many teams start this way and move to a managed broker when the operational load grows.
Is Kubernetes a good place to run an MQTT broker?
It can be if your team already runs Kubernetes well. MQTT's long-lived connections need TCP load balancing and careful rolling updates to avoid mass reconnects.
What is the difference between dedicated and BYOC hosting?
Both give you an isolated broker operated by the provider. Dedicated runs in the provider's infrastructure, while BYOC runs in your own cloud account.
