What Is a Managed MQTT Broker? Benefits, Costs and How to Choose

A managed MQTT broker is an MQTT server that someone else operates for you: you get a hostname, ports and credentials, and the provider takes care of servers, certificates, upgrades and capacity. In this guide you will learn what a managed MQTT broker actually does for you, how it compares to running your own broker, which deployment model fits your project and how to connect your first client in about five minutes.

If you are new to MQTT itself, start with What Is an MQTT Broker? and come back here when you are ready to think about hosting.

What Is a Managed MQTT Broker?

MQTT is a lightweight publish/subscribe protocol. Devices and applications never talk to each other directly; they connect to a broker, publish messages to topics and subscribe to the topics they care about. The broker is the single piece of infrastructure every message passes through, which makes it both simple and critical.

A self-hosted broker means you install broker software on a virtual machine or a Kubernetes cluster and own everything around it. A managed MQTT broker (sometimes called "MQTT broker as a service" or a cloud MQTT broker) moves that responsibility to a provider. In practice you receive:

• A public endpoint such as mqtts://your-broker:8883, plus WebSocket endpoints for browsers.
• Credentials (username, password, client ID) generated per broker.
• TLS with a valid, automatically renewed certificate.
• A web console to create brokers, inspect topics, watch connections and configure alerts.
• Plan-based limits for connections, message size and QoS that you can raise by changing plans instead of rebuilding infrastructure.

Your devices still speak plain, standard MQTT. That matters: you are not locked into a proprietary SDK, and any MQTT 3.1.1 or MQTT 5.0 client library works.

Managed vs Self-Hosted MQTT Broker

Running an open-source broker on a single VM is easy on day one. The work shows up later: certificate renewals, OS patches, the first time a fleet of devices reconnects at once, and the 3 a.m. question of whether the broker is even up. Here is how the responsibilities split.

Operations and patching

With a self-hosted broker, you track security advisories for the broker, the TLS library and the operating system, schedule maintenance windows and test upgrades. With a managed MQTT broker, the provider applies updates to the broker fleet, and you keep working against the same hostname and credentials.

Scaling

A single self-hosted node has a ceiling defined by its CPU, memory and file-descriptor limits. Raising it means resizing, tuning the kernel and sometimes redesigning. On a managed service you scale by moving to a plan with higher limits or to a dedicated cluster. ConnectMQ also protects shared infrastructure with per-plan quotas, connection-flood protection and adaptive overload protection, so a misbehaving client cannot take everyone else down.

TLS certificates

Encrypted MQTT on port 8883 requires a certificate that clients trust. Self-hosting means obtaining it, wiring renewal automation and restarting listeners. ConnectMQ serves TLS on 8883 and secure WebSocket on 8084 with a Let's Encrypt certificate, so standard clients trust it out of the box. For a deeper look at transport security, see MQTT Security Best Practices.

Monitoring

A bare broker gives you logs and, at best, $SYS topics. You still need dashboards, alerting and a way to see which device is connected. The ConnectMQ portal includes a dashboard, a live topic explorer, an in-browser MQTT client, a devices view organised by ISA-95 levels, threshold alert rules and an alerts log.

Total cost of ownership

The server bill is rarely the expensive part. The table below compares where effort goes.

Self-hosting still makes sense when data must never leave your network, when you have strict air-gap requirements or when you already run a platform team with spare capacity. For most teams shipping a product, a managed MQTT broker turns a recurring operations burden into a predictable subscription.

Managed MQTT Broker Deployment Models

"Managed" is not one thing. The right model depends on how much isolation you need and where your data must live. ConnectMQ offers four models that map to its plans.

Serverless (shared cluster)

You get a broker in seconds without choosing machine sizes. Each tenant's topics are isolated from other tenants and from the public area. The free Serverless plan is aimed at trials and prototypes: up to 25 concurrent connections, QoS up to 1, 256 KB messages, retained messages and wildcard subscriptions. The paid Serverless plan raises this to production limits on the same shared cluster: up to 1,000 connections, QoS 2, 1 MB messages and shared subscriptions.

Dedicated

A dedicated plan gives you an isolated broker cluster of your own. Noisy neighbours disappear from the equation and capacity is reserved for your workload, while ConnectMQ still operates it.

BYOC (Bring Your Own Cloud)

With BYOC, brokers run in your own cloud account and ConnectMQ manages them. This is useful when your security team requires data to stay inside your account boundary or when you want to use existing cloud spend.

Self Managed Enterprise

For factories, utilities and other sites where the broker must live on your own hardware, the Self Managed Enterprise plan provides a licensed broker you run on your infrastructure. It suits industrial setups; read MQTT Sparkplug B and Unified Namespace to see how ConnectMQ handles ISA-95 and Sparkplug B topic structures.

Unsure which to pick? Our guide on how to choose an IoT MQTT broker walks through the decision criteria.

Quickstart: Your First Managed MQTT Broker in 5 Minutes

You can try MQTT before creating an account, then move to a private broker with credentials.

Step 0: Test anonymously on the public broker

broker.connectmq.com has a public area. Connect with no username or password and a unique, non-empty client ID. Everything in the public area is readable by anyone, so use a random prefix and never send personal or sensitive data.

Open one terminal and subscribe:

mosquitto_sub -h broker.connectmq.com -p 1883 -i demo-sub-7f3k \
  -t "connectmq/demo/7f3k/#" -v

In a second terminal, publish:

mosquitto_pub -h broker.connectmq.com -p 1883 -i demo-pub-7f3k \
  -t "connectmq/demo/7f3k/room1/temp" -m '{"temp":22.5}' -q 1

The subscriber prints connectmq/demo/7f3k/room1/temp {"temp":22.5}. Public area limits are 64 KB per message, 10 messages per second per client, 10 subscriptions per client and up to 8 topic levels. Good for testing; for production you want your own broker.

Step 1: Sign up and create a broker

1. Go to app.connectmq.com and sign up. The free Serverless plan does not require a credit card.
2. Choose a plan and create a broker.
3. Copy the generated username, password and client ID. Your client ID is restricted to the issued value and its _suffix variants (for example YOUR_CLIENT_ID_sensor1), which lets you run several clients under one broker.

Step 2: Connect over TLS with mosquitto

Use port 8883 for encrypted MQTT. Because the certificate is issued by Let's Encrypt, pointing the client at your system CA store is enough. On Linux and macOS:

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID_sub \
  -t "factory1/line1/#" -v -V mqttv5

mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID_pub \
  -t "factory1/line1/cnc1/telemetry" -m '{"spindle_rpm":12000}' -q 1 -V mqttv5

On Windows, pass a CA bundle file with --cafile instead of --capath.

Step 3: Connect from Python

Install the client with pip install paho-mqtt (version 2.x), then run:

import json
import ssl
import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
PORT = 8883
USERNAME = "YOUR_USERNAME"
PASSWORD = "YOUR_PASSWORD"
CLIENT_ID = "YOUR_CLIENT_ID"
TOPIC = "factory1/line1/cnc1/telemetry"


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(TOPIC, qos=1)
    client.publish(TOPIC, json.dumps({"spindle_rpm": 12000}), qos=1)


def on_message(client, userdata, msg):
    print(f"{msg.topic} -> {msg.payload.decode()}")


client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id=CLIENT_ID,
    protocol=mqtt.MQTTv5,
)
client.username_pw_set(USERNAME, PASSWORD)
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message

client.connect(BROKER, PORT, keepalive=60)
client.loop_forever()

You should see Connected: Success followed by your own message. Open the live topic explorer in the portal and the same message appears there.

Step 4: Watch and alert

From the portal you can inspect topics as they arrive, check which clients are connected and add a threshold alert rule (for example, notify when spindle_rpm exceeds a limit). If you work in VS Code, the ConnectMQ extension shows CONNACK, SUBACK and PUBACK reason codes and charts numeric JSON fields live.

What to Check Before Choosing a Managed MQTT Broker

Whichever provider you evaluate, ask these questions:

• Protocol support: Does it support both MQTT 3.1.1 and MQTT 5.0? MQTT 5 features such as session expiry, message expiry, topic aliases and reason codes make fleets easier to operate.
• Transport options: TCP, TLS and WebSocket (including secure WebSocket for browser dashboards).
• Tenant isolation: Are your topics invisible to other customers on a shared cluster?
• Abuse protection: Quotas, flood protection and blocking of repeated bad-credential attempts.
• Limits that are announced, not guessed: An MQTT 5 broker can tell clients its limits in CONNACK (Maximum QoS, Retain Available, Wildcard and Shared Subscription Available, Receive Maximum). ConnectMQ does this, so clients can adapt instead of failing silently.
• Upgrade path: Can you move from a free shared broker to dedicated, your own cloud or on-premises without rewriting devices?

Get Started with ConnectMQ

Create your first managed MQTT broker at app.connectmq.com. The Serverless plan is free, needs no credit card and gives you credentials, TLS and a portal with a topic explorer in minutes. When you outgrow it, move to Serverless Paid, Dedicated, BYOC or Self Managed Enterprise without changing your MQTT code.

Frequently Asked Questions

What is a managed MQTT broker?

A managed MQTT broker is an MQTT server operated by a provider. You connect with standard MQTT clients using a hostname and credentials, while the provider handles servers, upgrades, TLS certificates, capacity and protection.

Is a managed MQTT broker more expensive than self-hosting?

The subscription can look higher than a single VM, but self-hosting also costs engineering time for patching, certificates, monitoring and on-call. For most teams the total cost of ownership is lower with a managed service, and ConnectMQ offers a free Serverless plan to start.

Can I use my existing MQTT client libraries?

Yes. ConnectMQ speaks standard MQTT 3.1.1 and MQTT 5.0 over TCP, TLS and WebSocket, so libraries such as Eclipse Paho, MQTT.js and PubSubClient work without changes.

Which ports should I use with ConnectMQ?

Use 8883 for MQTT over TLS and 8084 for secure WebSocket in production. Ports 1883 (TCP) and 8083 (WebSocket) are available for quick tests on the public broker.

Can I keep data in my own cloud or on-premises?

Yes. The BYOC plan runs ConnectMQ-managed brokers in your own cloud account, and the Self Managed Enterprise plan provides a licensed broker you run on your own infrastructure.