Public vs Private MQTT Broker: Which One Fits Your Project?

Choosing between a public vs private MQTT broker comes down to one question: who else can see and touch your messages? This guide explains how the two differ in privacy, authentication, limits and reliability, and shows exactly when and how to move from a public test broker to a private one without rewriting your code.

What a Public MQTT Broker Is

A public broker is an internet-reachable MQTT server that anyone can connect to without an account. You pick a client ID, subscribe to a topic and start publishing. Several exist; ConnectMQ runs one at broker.connectmq.com, described in detail in the free public MQTT broker article.

Public brokers are built for learning, demos, quick connectivity checks and sharing examples. They are intentionally open, which is exactly why they are not a place for real device data.

Key properties of a public broker:

• Anonymous access. No username or password, so anyone can connect.
• Shared topic space. Every client sees the same topic tree. If you subscribe to a topic, so can a stranger.
• Protective limits. To stay usable for everyone, public brokers cap message size, rate and subscriptions.
• No guarantees. They are a free community service, not a production platform.

What a Private MQTT Broker Is

A private broker accepts only clients with valid credentials. Its topic space belongs to you and your devices. It can be self-hosted or a managed service; either way, the defining traits are:

• Authentication. Clients present a username, password and usually a client ID that the broker recognises.
• Isolation. Other tenants cannot read or publish into your topics.
• Encryption by default. TLS on 8883 and Secure WebSocket on 8084 for browsers.
• Limits sized to your plan rather than to a crowd of anonymous users.

If you want the broader background on MQTT brokers, that article covers the publish/subscribe model itself.

Public vs Private MQTT Broker at a Glance

The protocol is identical. MQTT 3.1.1 and MQTT 5.0 behave the same on both; only access and limits change.

When a Public Broker Is the Right Tool

Use a public broker when the data has no value to anyone else and speed matters most:

1. Learning MQTT. Publish, subscribe, try wildcards and retained messages in minutes.
2. Workshops and classrooms. Every attendee connects with nothing to configure.
3. Testing a new library or board. Confirm that your ESP32 or Python script can reach a broker at all.
4. Sharing a reproducible example. A blog post or bug report that anyone can run.

A quick test looks like this:

# Subscribe with a unique prefix so you are not mixed with other users
mosquitto_sub -h broker.connectmq.com -p 1883 -i demo-sub-c41d -t "connectmq/demo/c41d/#" -v

# Publish from another terminal
mosquitto_pub -h broker.connectmq.com -p 1883 -i demo-pub-c41d -t "connectmq/demo/c41d/hello" -m "it works"

Always use a random, unique topic prefix such as connectmq/demo/c41d/. It keeps your test traffic separate from others, though it does not make it private.

When You Need a Private Broker

Switch to a private broker as soon as any of these is true:

• The data identifies a person, home, vehicle or location. Sensor values that reveal when a house is empty are sensitive.
• Devices accept commands. On a public broker, anyone can publish to your command topic.
• You are running a pilot with a customer. They will expect authentication and encryption.
• You need larger messages, more throughput or more subscriptions than public limits allow.
• Uptime matters. A public test service is not something to build a product on.

The public MQTT broker limitations article explains each of these constraints in more depth.

Moving From Public to Private Without Rewrites

Because both sides speak standard MQTT, the switch is a configuration change. Here is a Python example using paho-mqtt 2.x that reads its target from environment variables, so the same code runs against both:

import os
import ssl
import paho.mqtt.client as mqtt

HOST = os.getenv("MQTT_HOST", "broker.connectmq.com")
PORT = int(os.getenv("MQTT_PORT", "1883"))
USERNAME = os.getenv("MQTT_USERNAME")          # unset for the public broker
PASSWORD = os.getenv("MQTT_PASSWORD")
CLIENT_ID = os.getenv("MQTT_CLIENT_ID", "demo-c41d-py")
TOPIC = os.getenv("MQTT_TOPIC", "connectmq/demo/c41d/temp")


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(TOPIC, qos=1)
    client.publish(TOPIC, "21.7", qos=1)


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


client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id=CLIENT_ID,
    protocol=mqtt.MQTTv5,
)
client.on_connect = on_connect
client.on_message = on_message

if USERNAME:
    client.username_pw_set(USERNAME, PASSWORD)
if PORT == 8883:
    client.tls_set(cert_reqs=ssl.CERT_REQUIRED)

client.connect(HOST, PORT, keepalive=60)

try:
    client.loop_forever()
except KeyboardInterrupt:
    client.disconnect()

For the private broker, set the variables from your ConnectMQ portal:

export MQTT_HOST=broker.connectmq.com
export MQTT_PORT=8883
export MQTT_USERNAME=YOUR_USERNAME
export MQTT_PASSWORD=YOUR_PASSWORD
export MQTT_CLIENT_ID=YOUR_CLIENT_ID
export MQTT_TOPIC=plant1/line1/temp
python client.py

Note that on ConnectMQ the client ID is bound to the issued credentials, so use the client ID the portal generated rather than inventing a new one.

Common Mistakes When Switching

• Leaving port 1883 in production firmware. Use 8883 (TLS) for devices and 8084 with path /mqtt for browsers.
• Keeping the demo topic prefix. Rename topics to a real structure, for example site/area/line/device. The cloud MQTT broker guide has guidance on topic design for hosted brokers.
• Hard-coding credentials in a public repository. Load them from environment variables, a secrets store or device provisioning.
• Reusing one client ID on several devices. The broker will disconnect the older session each time the other connects, causing a reconnect loop.
• Assuming QoS 2 everywhere. The free Serverless plan supports QoS up to 1. If you need QoS 2, use a paid plan or design for idempotent QoS 1 handling. See MQTT QoS levels explained.

Security Checklist for Your Private Broker

Moving to a private broker removes anonymous access, but a few habits decide how secure the result really is:

1. One credential set per device or service. If a device is lost or compromised you can revoke it without touching the others.
2. TLS everywhere outside the lab. Verify the server certificate in your client rather than disabling verification to get past an error.
3. Separate telemetry and command topics. Make it obvious in the topic tree which messages change the state of real equipment, and review who publishes to them.
4. Watch the connection log. Repeated failed logins usually mean a misconfigured device or a credential that leaked. Your broker may block an IP after repeated failures, but you still want to find the cause.
5. Keep a test topic prefix for experiments so that debugging traffic never mixes with production data.

The MQTT security best practices guide goes deeper into each of these points.

A Simple Rule of Thumb

Use the public broker for anything you would be comfortable posting on a forum. Use a private broker for everything else. Because the move costs only a few configuration values, there is no reason to keep real devices on a public broker longer than the first afternoon.

Get Your Private Broker on ConnectMQ

When you are ready to move beyond tests, sign up for a free Serverless plan with no credit card required. Create a broker, copy the generated username, password and client ID, and point the same code at port 8883. The portal's in-browser MQTT client and live topic explorer let you confirm traffic immediately. Learn more about ConnectMQ and how a hosted MQTT broker removes the operations work.

Frequently Asked Questions

Can other people see my messages on a public MQTT broker?

Yes. Anyone can subscribe to any topic on a public broker, including wildcards like #. Never send personal data, credentials or commands that control real equipment.

Is a private MQTT broker always encrypted?

Not automatically, but a good managed private broker offers TLS on 8883 and Secure WebSocket on 8084. Use those ports in production rather than plain TCP on 1883.

Do I need to change my code to move from public to private?

Usually only the host, port, credentials and client ID change. If your code reads them from configuration, the switch takes minutes.

Is a free private broker enough for a prototype?

For many prototypes, yes. ConnectMQ's free Serverless plan allows up to 25 connections, QoS up to 1 and 256 KB messages, which covers most small pilots.