Cloud MQTT Broker: The Complete Guide to Hosted MQTT

A cloud MQTT broker gives your devices, apps and services a reliable, internet-reachable message hub without you installing, patching or scaling a server. This guide explains what a hosted broker is, how the deployment models differ, what to check for security, limits and cost, and how to move from a laptop prototype to production. At the end you will have a working connection to a private broker and a checklist for choosing a provider.

What Is a Cloud MQTT Broker?

An MQTT broker is the server that receives every published message and routes it to every matching subscriber. If you need a refresher on that role, start with what an MQTT broker does. A cloud MQTT broker is the same software running on infrastructure operated by a provider and exposed through a public hostname. You get endpoints, credentials and a management console; the provider handles servers, operating systems, TLS certificates, upgrades and capacity.

The difference from "a VM with Mosquitto on it" is responsibility. With a VM in the cloud, you still own the broker: configuration, certificates, monitoring, security patches and the 3 a.m. outage. With a hosted broker, those become the provider's job, and you consume MQTT as a service. That model is often called MQTT broker as a service, and it is the reason most new IoT projects start in the cloud rather than on a server in a closet.

Why Teams Move MQTT to the Cloud

• Reachability. Devices in the field connect over the public internet to one stable hostname, with no inbound firewall rules or port forwarding at each site.
• Time to first message. Creating a broker takes minutes instead of days of server hardening.
• Operational load. Certificate renewals, OS patches, broker upgrades and capacity planning stop being your team's work.
• Elastic growth. Moving from ten test devices to thousands is a plan change, not a re-architecture.
• Built-in tooling. A good provider ships a web client, a topic explorer and connection visibility, which you would otherwise assemble yourself.

The trade-offs are real too: you depend on the provider's availability and roadmap, data leaves your premises, and you work within plan quotas. We weigh both sides in self-hosted vs managed MQTT broker.

Cloud MQTT Broker Deployment Models

"Cloud broker" covers several very different architectures. Knowing which one you are buying matters more than any feature list.

Serverless

A serverless MQTT broker runs on a shared, multi-tenant cluster. You create a broker in seconds, pay nothing or little at small scale and never think about instances. Good providers enforce strict tenant isolation, per-plan quotas and flood protection so one noisy tenant cannot hurt others. The constraints are connection, message size and throughput limits set by the plan. How that isolation works is covered in multi-tenant MQTT brokers.

Dedicated

A dedicated MQTT broker gives you an isolated cluster. Nobody else shares your CPU, memory or network, so latency and throughput are more predictable, and limits are sized to your workload rather than a shared tier.

BYOC

With a BYOC MQTT broker, the broker runs inside your own cloud account, so data stays in infrastructure you control and spend counts toward your existing cloud agreements, while the provider still operates the broker for you. This is often the answer for regulated industries; see MQTT data residency for the compliance side.

Self-Managed Enterprise

Some environments, such as plants with no internet egress, cannot use any external service. A self-managed edition lets you run the same broker software on your own hardware, with your team operating it.

Security in a Hosted MQTT Broker

Moving to the cloud puts your broker on the public internet, so security is not optional. The essentials, in order of importance:

1. TLS on every connection. Use port 8883 for MQTT over TLS and 8084 for Secure WebSocket. Plain 1883 is acceptable only for throwaway tests on non-sensitive data.
2. Unique credentials per device or service. Shared passwords turn one compromised device into a compromised fleet.
3. Client ID binding. When client IDs are tied to issued credentials, a stolen password cannot be used to impersonate another device.
4. Brute-force protection. The broker should block IP addresses after repeated failed logins.
5. Tenant isolation. On shared infrastructure, verify that one customer's topics are invisible to another's.
6. Flood protection and quotas. A misbehaving client stuck in a publish loop should be throttled, not allowed to take the broker down.
7. Payload hygiene. Never put secrets or personal data in topic names; topic strings appear in logs and tools.

The full list, including certificate pinning on devices and credential rotation, is in our MQTT security best practices.

Limits and Quotas You Must Understand

Every hosted broker enforces limits, and they shape your design more than most people expect. Ask for these numbers before committing:

When a client exceeds a quota on an MQTT 5 broker, it receives a reason code instead of a silent drop; 0x97 (Quota exceeded) is the one to watch for. Our article on MQTT broker connection quotas explains how to size them.

How Cloud MQTT Pricing Works

Providers price hosted MQTT in a few recognizable ways:

• By connection count, often the dominant factor for device fleets.
• By message volume or throughput, which matters for high-frequency telemetry.
• By cluster or instance, typical for dedicated deployments.
• By feature tier, where QoS 2, larger messages or shared subscriptions unlock on higher plans.

The cheapest plan on paper is not always the cheapest system. Factor in engineering time for operations, the cost of outages, and the effort to leave if the provider does not work out. MQTT broker pricing breaks down the models, and total cost of ownership compares managed and self-hosted spend over time. Lock-in risk is lowest when the provider speaks standard MQTT with no proprietary SDK, which we cover in avoiding MQTT vendor lock-in.

Connecting to an MQTT Broker in the Cloud: Hands-On

The fastest way to understand hosted MQTT is to use one. Start on the shared public MQTT test broker at broker.connectmq.com, which needs no account. Use a unique client ID and a unique topic prefix, and remember that the public area is readable by everyone:

# Terminal 1: subscribe
mosquitto_sub -h broker.connectmq.com -p 1883 -i cloud-sub-r4t7 \
  -t "connectmq/demo/r4t7w2/#" -v

# Terminal 2: publish
mosquitto_pub -h broker.connectmq.com -p 1883 -i cloud-pub-r4t7 \
  -t "connectmq/demo/r4t7w2/sensor1/temp" -m "22.4"

For a private broker, the flow looks like this:

1. Sign up at app.connectmq.com and choose a plan.
2. Create a broker.
3. Copy the generated username, password and client ID from the portal.
4. Connect over TLS on port 8883 (or WSS on 8084 with path /mqtt from browsers).

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i YOUR_CLIENT_ID -u YOUR_USERNAME -P YOUR_PASSWORD \
  -t "plant1/#" -v

The certificate is issued by Let's Encrypt, so standard CA bundles verify it. On macOS and Windows use --cafile with a CA bundle file instead of --capath.

A Production-Style Client in Python

This paho-mqtt 2.x client connects with credentials, announces presence with a retained status and a Last Will, and uses MQTT 5 message expiry so stale readings are not delivered to subscribers that come online much later:

import json
import time

import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties

BASE = "plant1/line1/sensor1"

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("Connect failed:", reason_code)
        return
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)
    client.subscribe(f"{BASE}/cmd", qos=1)

def on_message(client, userdata, msg):
    print("Command:", msg.payload.decode())

client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id="YOUR_CLIENT_ID",
    protocol=mqtt.MQTTv5,
)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.tls_set()
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.on_connect = on_connect
client.on_message = on_message

client.connect("broker.connectmq.com", 8883, keepalive=30)
client.loop_start()

props = Properties(PacketTypes.PUBLISH)
props.MessageExpiryInterval = 60  # seconds

while True:
    payload = json.dumps({"temp": 22.4, "ts": int(time.time())})
    client.publish(f"{BASE}/telemetry", payload, qos=1, properties=props)
    time.sleep(10)

In the ConnectMQ portal you can watch these messages arrive in the live topic explorer, send a command back from the in-browser MQTT client, and check whether a given client is connected by subscribing to $SYS/broker/connection/{clientId}/state.

Integrating a Cloud Broker With the Rest of Your Stack

A broker routes messages; it does not store them in your database or call your APIs. The clean, portable pattern is to connect integration tools as ordinary MQTT clients:

• Time-series storage: Telegraf's MQTT consumer writing to InfluxDB, or a small Python subscriber writing to PostgreSQL or TimescaleDB.
• Flows and automation: Node-RED with an mqtt-broker config node pointing at your broker on 8883 with TLS.
• Dashboards: Grafana on top of the database, or a browser app using MQTT.js over WSS.
• Smart home: Home Assistant's MQTT integration.

Because each of these is a standard client, you can swap or add tools without touching device firmware. For load-balanced backend consumers, MQTT 5 shared subscriptions ($share/group/topic) distribute messages across several workers; they are typically reserved for paid tiers, as in the plan table below.

Choosing a Cloud MQTT Broker Provider

Use this checklist when you compare providers. It complements our broader guide on how to choose an IoT MQTT broker.

1. Supports MQTT 3.1.1 and 5.0 with standard clients, no proprietary SDK required.
2. Offers TLS and Secure WebSocket endpoints with a publicly trusted certificate.
3. Publishes clear quotas for connections, message size, QoS and rate.
4. Provides a free tier or public test broker to validate your clients before you pay.
5. Offers a path from shared to dedicated or BYOC without changing client code.
6. Gives you visibility: connection state, live topic view and alerting on values that matter.
7. Documents tenant isolation and abuse protection on shared plans.
8. Answers your data residency and support questions in writing.

Before launch, run through the MQTT production checklist, and if you are leaving a self-hosted Mosquitto, the steps in migrating Mosquitto to a cloud MQTT broker will save you a few surprises. Once you are live, MQTT broker monitoring explains which signals to watch.

How ConnectMQ Fits

ConnectMQ is a hosted MQTT broker built around the deployment models described above:

Every broker supports MQTT 3.1.1 and 5.0 on TCP 1883, TLS 8883, WebSocket 8083 and Secure WebSocket 8084, with a Let's Encrypt certificate. The portal includes an in-browser MQTT client, a live topic explorer, a dashboard, a devices view organized by ISA-95 levels, and threshold alert rules with an alerts log, in English or Turkish. On the security side you get multi-tenant isolation, per-plan quotas, flood protection, IP blocking after repeated failed logins and client IDs bound to issued credentials. For industrial users, ConnectMQ also detects ISA-95 and Unified Namespace topics and decodes Sparkplug B payloads.

What it deliberately does not do is replace your data stack: there is no built-in rule engine or database bridge, so storage and automation are handled by standard MQTT clients such as Telegraf, Node-RED or your own services, as described above.

Start Your Cloud MQTT Broker Free

Test your clients on broker.connectmq.com today, then create a private broker at app.connectmq.com. The Serverless free plan needs no credit card, and the same credentials and code carry over when you move to a paid, dedicated or BYOC plan.

Frequently Asked Questions

What is the difference between a cloud MQTT broker and a managed MQTT broker?

In practice the terms overlap. "Cloud" describes where the broker runs and how devices reach it, while "managed" describes who operates it; most hosted offerings are both, but a VM running your own Mosquitto is cloud-hosted without being managed.

Is a cloud MQTT broker secure enough for industrial data?

It can be, if you use TLS on every connection, unique credentials per device, and a deployment model that matches your requirements. Plants with strict data residency rules often choose dedicated or BYOC deployments instead of a shared tier.

Can I use a free cloud MQTT broker in production?

A free tier is suitable for small, non-critical deployments within its limits, such as up to 25 connections on ConnectMQ's Serverless free plan. The anonymous public broker is never suitable for production because anyone can read its public area.

Do I need a special SDK to connect to a hosted MQTT broker?

Not with a standards-based provider. Any MQTT 3.1.1 or 5.0 client works, including paho-mqtt, MQTT.js, MQTTnet, PubSubClient and the Mosquitto CLI tools.

How do I store data from a cloud MQTT broker in a database?

Run a subscriber that writes to your database, such as Telegraf for InfluxDB or a short Python script for PostgreSQL. The broker delivers the messages; the subscriber decides where they are stored.