MQTT Broker as a Service: What You Get and What You Don't

An MQTT broker as a service gives you a working, secured broker endpoint without installing, patching or monitoring a server yourself. This article explains exactly which responsibilities move to the provider, which stay with you, and how to build the pieces a broker does not include, so you can set the right expectations before you sign up.

What "MQTT Broker as a Service" Means

As a service means you consume the broker as an endpoint, not as software you run. You receive a hostname, ports, credentials and a management portal. The provider runs the machines, the broker software, TLS certificates and the operational processes behind them. You connect devices and applications using standard MQTT, exactly as you would to a broker you host yourself.

That last point matters. Because MQTT is an open standard, the same client libraries, firmware and tools work whether the broker runs on a Raspberry Pi in your office or on a provider's cloud. If you are new to the protocol, start with what an MQTT broker does.

The Responsibility Split

The table below shows a typical split. The right-hand column uses ConnectMQ as a concrete reference.

What You Get

No servers to run

You never install Mosquitto, configure systemd units, raise file descriptor limits or schedule OS patches. On Serverless plans you also never think about machine sizing; you choose a plan with the limits you need.

Security defaults that are hard to get wrong

TLS is ready on day one with a publicly trusted certificate, credentials are generated rather than chosen by hand, and client IDs are bound to the credentials issued for them. Brute-force login attempts lead to IP blocking. Self-hosted brokers often launch without some of these protections and add them later. Our MQTT security best practices article covers the client side of the same story.

Predictable limits

Plans come with published limits. On ConnectMQ, the Serverless (Free) plan allows up to 25 connections, QoS up to 1 and 256 KB messages; the paid Serverless plan allows up to 1,000 connections, QoS 2, 1 MB messages and shared subscriptions. Dedicated, BYOC and Self Managed Enterprise cover isolated and customer-controlled deployments.

Tools for seeing what is happening

A broker you cannot see into is hard to debug. A good service gives you a way to publish test messages, watch live topics, see which devices are connected and get notified when values cross a threshold, all from a browser.

What You Don't Get

Being clear about this avoids disappointment later.

A broker is not a database. It routes messages; it does not keep history. Retained messages store only the last value per topic. If you need charts over time, you need a time-series database or historian.

A broker is not an integration platform. Some IoT platforms bundle rule engines, webhooks and connectors to databases or other clouds. A pure broker as a service, ConnectMQ included, does not. You build integrations by running a client that subscribes and forwards.

A broker does not make clients reliable. Reconnect logic, local buffering, idempotent commands and sensible QoS choices live in your code. See MQTT broker high availability for client patterns.

A broker does not design your topics. A clear namespace is your job, and it decides how easy everything else will be.

The Integration Pattern: Subscribe and Forward

The honest, portable way to connect a broker as a service to the rest of your stack is a small subscriber process. It works with any broker and keeps you free to change databases or providers later. Here is a complete Python example that stores every telemetry message in SQLite. Swap SQLite for PostgreSQL, InfluxDB or a file as needed.

# store_telemetry.py - subscribe to telemetry and store it in SQLite
import json
import sqlite3
import time

import paho.mqtt.client as mqtt

DB = sqlite3.connect("telemetry.db", check_same_thread=False)
DB.execute("""CREATE TABLE IF NOT EXISTS telemetry (
                ts REAL, topic TEXT, payload TEXT)""")
DB.commit()

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe("acme/+/+/+/+/telemetry", qos=1)

def on_message(client, userdata, msg):
    try:
        payload = json.dumps(json.loads(msg.payload))   # validate JSON
    except ValueError:
        print("skipping non-JSON message on", msg.topic)
        return
    DB.execute("INSERT INTO telemetry VALUES (?, ?, ?)",
               (time.time(), msg.topic, payload))
    DB.commit()

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id="YOUR_CLIENT_ID", protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

The same pattern applies to low-code tools. Node-RED connects with an mqtt-broker config node, Telegraf uses its MQTT consumer input, and Home Assistant uses its MQTT integration. Each is simply another MQTT client of the broker.

Choosing the Right Service Level

If you are weighing service against running your own, read self-hosted vs managed MQTT broker and MQTT broker hosting options compared. The cloud MQTT broker guide is the overview for this whole topic.

Questions to Ask Before Choosing a Provider

1. Which MQTT versions and transports are supported?
2. What are the exact limits for connections, message size and QoS on each plan?
3. How are credentials issued, rotated and revoked?
4. How does the service signal quota violations to clients?
5. What visibility tools are included?
6. What is not included, such as storage, rule engines or connectors?
7. What isolation options exist beyond shared plans?
8. What are the SLA terms, in writing?
9. How easy is it to leave, given that devices only know a hostname and credentials?

Try MQTT as a Service with ConnectMQ

ConnectMQ runs the broker, TLS and quotas so you can focus on devices and data. Sign up at app.connectmq.com, create a broker on the free Serverless plan with no credit card, and connect your first client in minutes.

Frequently Asked Questions

What does an MQTT broker as a service include?

Typically the broker software, servers, patching, TLS certificates, endpoints, credentials, quotas and a management portal. You keep responsibility for devices, topics, payloads and data storage.

Does a managed MQTT broker store my data?

A broker routes messages and keeps only retained last values per topic. For history, run a subscriber that writes messages to a database you control.

Can I connect Node-RED or Telegraf to a broker as a service?

Yes. They connect as ordinary MQTT clients using the hostname, port and credentials from the portal, then forward data wherever you need it.

Is it hard to move away from an MQTT broker as a service?

Because MQTT is a standard, devices only need a new hostname and credentials. Avoiding proprietary features keeps switching costs low.