A serverless MQTT broker gives you a working MQTT endpoint, credentials and a dashboard without provisioning a single server, because your broker lives on a shared, multi-tenant cluster run by the provider. In this guide you will learn how the serverless model works under the hood, which usage limits actually matter, which workloads it suits, and how to create and test a free serverless broker on ConnectMQ step by step.
What "Serverless" Means for an MQTT Broker
There are obviously still servers involved. "Serverless" describes who owns them and how you consume them. With a self-hosted broker such as Mosquitto on a virtual machine, you pick the machine size, install packages, open firewall ports, renew TLS certificates and patch the operating system. With a serverless MQTT broker, all of that is the provider's job. You receive a hostname, ports, a username, a password and a client ID, and you start publishing.
The core idea is multi-tenancy. One well-sized broker cluster serves many customers at the same time. Each customer gets a logically isolated "broker" on that cluster: its own credentials, its own topic space and its own quotas. Because capacity is pooled, the provider can offer a small tier free or very cheaply, and you never pay for an idle virtual machine sitting at 2% CPU.
If you need a refresher on the broker's role itself, see what an MQTT broker does before continuing.
How Tenant Isolation Works
A shared cluster is only safe if tenants cannot see or disturb each other. A well-designed serverless broker enforces isolation at several layers:
- Authentication. Every connection presents credentials issued to one tenant. Here, client IDs are bound to the issued credentials, so another tenant cannot impersonate your devices.
- Topic namespacing. Your topics are scoped to your broker, so a subscription to
#only ever returns your own traffic. - Quotas. Connection counts, message size and QoS level are enforced per plan, so one tenant cannot exhaust shared resources.
- Abuse protection. Flood protection and IP blocking after repeated failed logins keep a misbehaving client from degrading the cluster for everyone.
When a quota is hit, an MQTT 5 client receives a meaningful reason code (for example 0x97, quota exceeded) rather than a silent drop, which makes limits debuggable instead of mysterious.
Serverless vs Dedicated vs Self-Hosted
The serverless tier is one of several ways to consume a fully managed MQTT service. The table compares the common options.
| Aspect | Self-hosted | Serverless (shared) | Dedicated (isolated) |
|---|---|---|---|
| Who runs servers | You | Provider | Provider |
| Time to first message | Hours to days | Minutes | Provisioning step |
| Capacity | Whatever you size | Pooled, plan quotas | Reserved for you |
| Noisy neighbours | None | Mitigated by quotas | None |
| Idle cost | Full VM cost | Free or low | Reserved capacity |
| Best for | Full control, air-gapped sites | Prototypes, small fleets, education, early products | Production fleets with steady load |
The honest trade-off: serverless gives up reserved capacity and some configurability in exchange for zero operations and near-zero cost at small scale. When you need guaranteed isolation and predictable headroom, a dedicated MQTT broker is the next step.
Limits That Matter on a Serverless MQTT Broker
Every shared tier publishes quotas. Read them as design constraints, not fine print. ConnectMQ's serverless plans look like this:
| Limit | Serverless (Free) | Serverless (Paid) |
|---|---|---|
| Concurrent connections | Up to 25 | Up to 1,000 |
| Maximum QoS | 1 | 2 |
| Maximum message size | 256 KB | 1 MB |
| Shared subscriptions | No | Yes |
| Protocols | MQTT 3.1.1 and 5.0 | MQTT 3.1.1 and 5.0 |
What these mean in practice:
- Connections are the scarce resource. Each device, each dashboard tab and each backend worker holds one connection. Twenty sensors plus a Node-RED instance plus two browser dashboards is already 23 connections. Count them before you deploy.
- QoS 1 covers most telemetry. At-least-once delivery with idempotent consumers handles almost every sensor workload. If you truly need exactly-once semantics, read MQTT QoS levels explained and consider the paid tier.
- Message size rarely bites telemetry. A JSON reading is a few hundred bytes. Images and firmware chunks are where 256 KB matters; publish a URL to object storage rather than the file itself.
- Shared subscriptions enable horizontal consumers. If you plan to run several backend workers that split one topic stream, you need
$share/group/topic, which is available on the paid serverless tier.
Workloads That Fit Serverless
A serverless MQTT broker is an excellent fit for:
- Prototypes and proofs of concept. You can go from idea to a working device-to-dashboard loop in an afternoon.
- Small production fleets. A building with a dozen sensors, a greenhouse controller or a small retail deployment fits comfortably inside connection quotas.
- Classrooms and hackathons. Each team gets an isolated broker without anyone running infrastructure.
- Early-stage products. Startups can validate the market before committing to reserved capacity. Our guide to choosing an MQTT broker for startups covers the growth path.
- Development and staging environments. Even teams with a dedicated production broker often keep a serverless broker for development.
It is a weaker fit when you have thousands of always-on devices, strict latency budgets under sustained high throughput, or a policy that forbids shared infrastructure.
Walkthrough: Create a Free ConnectMQ Serverless Broker
Step 1: Sign Up and Create the Broker
Go to ConnectMQ, open the portal, choose the Serverless (Free) plan and create a broker. The portal generates a username, a password and a client ID. Copy them somewhere safe; treat the password like any other secret.
Step 2: Test with the In-Browser Client
The portal includes an in-browser MQTT client and a live topic explorer. Subscribe to test/#, publish to test/hello, and confirm the message appears. This verifies credentials before any device code is involved.
Step 3: Connect from the Command Line
With Mosquitto clients installed, connect over TLS on port 8883:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID -t 'sensors/#' -v
The broker uses a Let's Encrypt certificate, so the system CA bundle is enough; no custom CA file is required.
Step 4: Publish from Python
This script uses paho-mqtt 2.x with the version 2 callback API and publishes a reading every five seconds.
import json
import random
import ssl
import time
import paho.mqtt.client as mqtt
HOST = "broker.connectmq.com"
PORT = 8883
USERNAME = "YOUR_USERNAME"
PASSWORD = "YOUR_PASSWORD"
CLIENT_ID = "YOUR_CLIENT_ID"
def on_connect(client, userdata, flags, reason_code, properties):
print(f"Connected: {reason_code}")
def on_disconnect(client, userdata, flags, reason_code, properties):
print(f"Disconnected: {reason_code}")
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_disconnect = on_disconnect
client.connect(HOST, PORT, keepalive=60)
client.loop_start()
try:
while True:
reading = {"temp_c": round(random.uniform(20, 25), 2), "ts": int(time.time())}
info = client.publish("sensors/room1/temperature", json.dumps(reading), qos=1)
info.wait_for_publish()
print("Published", reading)
time.sleep(5)
except KeyboardInterrupt:
pass
finally:
client.loop_stop()
client.disconnect()
If you just want to experiment without signing up, swap in the public MQTT test broker on port 1883, drop the credentials, use any non-empty unique client ID and a unique topic prefix such as connectmq/demo/a7f3k2/.... Remember that the public area is readable by everyone, so never send real data there.
Step 5: Watch Usage in the Dashboard
The portal dashboard shows your broker's activity, and the devices view groups clients by ISA-95 levels when your topics follow that structure. You can also define threshold alert rules (for example, temperature above 30) and review triggered alerts in the alerts log.
Design Tips for Staying Within Quotas
- Reuse connections. A gateway that aggregates ten BLE sensors into one MQTT connection uses one slot, not ten.
- Close idle dashboards. Browser tabs over WebSocket count as connections while open.
- Use retained messages for state. Publishing the last known value as retained lets new subscribers read current state instantly without polling.
- Set a sensible keep alive. 30 to 60 seconds is typical. Very short intervals waste traffic; very long ones delay disconnect detection.
- Handle reason codes. Log CONNACK and DISCONNECT reason codes so a quota refusal shows up clearly in your logs.
- Use unique client IDs. Two devices sharing one ID will keep kicking each other off; this is the single most common cause of "my client keeps reconnecting".
Moving Beyond Serverless
Outgrowing the free tier is a good problem. The path is usually Serverless (Free) for development, Serverless (Paid) for an early product with up to 1,000 connections and shared subscriptions, then Dedicated when you want an isolated cluster. Because everything speaks standard MQTT 3.1.1 and 5.0, moving tiers means updating hostname and credentials, not rewriting device firmware logic. For the bigger picture of hosting options, read our cloud MQTT broker guide, and see how to choose an IoT MQTT broker for an evaluation checklist.
Start Your Serverless Broker on ConnectMQ
You can create a free Serverless broker at app.connectmq.com with no credit card. Pick the Serverless (Free) plan, create a broker, copy the generated credentials and run the Python script above. You will have devices publishing over TLS within minutes, plus a topic explorer, dashboard and alert rules to watch them, while the provider handles the cluster.
Frequently Asked Questions
Is a serverless MQTT broker secure enough for production?
Yes, for many workloads. Traffic is encrypted with TLS, credentials are per tenant and client IDs are bound to them; choose a dedicated or BYOC deployment if policy forbids shared infrastructure.
What happens when I exceed the connection limit?
The broker refuses the extra connection. MQTT 5 clients receive a reason code such as quota exceeded, so you can log it and react rather than guess.
Can I use MQTT 5 features on the free tier?
Yes. MQTT 3.1.1 and 5.0 are both supported, including retained messages, session expiry, message expiry and topic aliases; QoS is capped at 1 and shared subscriptions require the paid serverless plan.
Do I need to change my device code to upgrade plans?
Usually not. Upgrading changes quotas, and moving to a dedicated broker typically means updating hostname and credentials while the MQTT logic stays the same.
Is the public test broker the same as a serverless broker?
No. The public broker at broker.connectmq.com accepts anonymous connections and everything is readable by anyone, while a serverless broker gives you private, authenticated credentials and your own quotas.
