Product · Guide
One MQTT broker, built into the platform.
Your devices, gateways and SCADA systems connect to MaestroHub directly. There is no separate MQTT broker to buy, install or keep patched, and your data and saved sessions come through replica failures and upgrades.
Buildingfor 3.0, not in a released version yetOn Kubernetes, every replica of the Unified Namespace service runs the broker, and together they act as one.
No separate broker to run
The broker runs inside MaestroHub's Unified Namespace service and is deployed by the same Kubernetes chart. It is the only MQTT broker MaestroHub uses, so there is no second product to size, license, secure or upgrade on its own schedule.
Data kept through failures and upgrades
A device is told its value is in only once MaestroHub has stored it. Saved sessions move to another replica when one fails or restarts, and replicas are upgraded one at a time while devices keep publishing.
Security and workspaces built in
Each device signs in as its own OAuth2 client and gets that client's permissions. It writes only into its own inbox, and every delivery to a subscriber is checked against what that subscriber may read.
How it fits together
Devices see one address.
Behind it, each replica serves any device, passes live values straight to the other replicas, and keeps what must survive a failure in a shared store the chart deploys with it.
How it stays up
A replica goes down. Here is what your plant sees.
Say the replica serving a line's gateways crashes, or is restarted for an upgrade. This is the order of events.
Replica B is gone. Gateways 2 and 3 still hold the values they were not told about. Everything they were told about is stored.
What we promise about your data
A confirmed value is never lost.
Confirmed means stored
For QoS 1 and 2, the broker confirms a device's value only after it is stored. If it cannot be stored in time, the device is told no, and sends it again. A value is never confirmed and then lost.
Exactly once, from device to subscriber
A value a device publishes at QoS 2 reaches a subscriber that asked for QoS 2 once, also when a replica fails in the middle of the exchange, with one documented edge case where it may arrive twice and is never lost.
Saved sessions survive
A persistent session outlives the replica that served it, and outlives a rolling upgrade.
Rolling upgrades
Replicas are upgraded one at a time while devices keep publishing. Old and new replicas write only what both can read until the last old one is gone.
History as the backstop
Every value is stored in the historian, so anything a subscriber missed live can be read back.
Security and workspaces
Every device signs in. Every delivery is checked.
One identity per device
Devices sign in with OAuth2 client credentials and get exactly that client's topic permissions. A revoked or rotated credential ends the session.
Writes go through an inbox
A device publishes only into its own inbox, and MaestroHub admits each value through the same checks as its REST API: schema, permissions, quality, alerts and history.
Reads checked on every delivery
Each value is checked against what the subscriber may read, whichever replica it comes from, so a removed permission stops delivery.
Workspaces are walled
Writes stay inside the device's own workspace, and a workspace whose saved-session store falls behind holds up only its own devices.
Separate service logins
With the production settings, each MaestroHub service signs in to the shared store as its own user, and the broker's state sits in an account no other service can read.
Limits against misbehaving devices
Caps on connections per credential and per address, connection size, subscriptions and topic depth, and a throttle on repeated failed sign-ins. TLS with your own certificate, optionally mutual TLS.
Before you plan on it
What to know first.
The boundaries, stated before you ask.
- It depends on the shared store. The replicas share sessions and membership through a NATS JetStream cluster the chart deploys. If every server of it is down, the broker stops taking connections until it is back, and nothing it confirmed is lost. If it is very slow, the broker steps aside safely and recovers on its own.
- High availability needs Kubernetes. A single machine runs one broker with no cluster: its saved sessions are kept in memory, so a restart starts them fresh. You provide the Kubernetes nodes.
- Live values between replicas are live only. If the link between two replicas is cut, live subscribers on the other side miss values for that time. Saved sessions do not, and the historian has every value.
- Shared subscriptions are not offered yet. They are planned. Topic aliases and subscription identifiers are coming in the next release.
Check it yourself
Break it on purpose.
In our test runs we break the cluster on purpose on Kubernetes: replicas crashed and restarted one by one, a store server killed, a replica's network cut, while devices publish and saved sessions subscribe, and a checker confirms every confirmed value reached every saved session in order. The broker is also tested against third-party MQTT clients, the Eclipse Paho libraries among them, and against hostile traffic such as connection floods and malformed packets.
You should not take that on trust. In a pilot, run the outage drill yourself.
The outage drill
- 1Kill the replica your devices are on, while they publish.
- 2Read back what your subscribers received.
- 3Compare it with what the historian stored.
Questions
Do I need a separate MQTT broker with MaestroHub?
Not with the built-in broker. Your devices, gateways and SCADA systems connect to MaestroHub directly, over MQTT 3.1.1 or 5, with TLS or WebSocket. The broker runs inside MaestroHub's Unified Namespace service and is deployed by the same Kubernetes chart, so there is no second product to size, license, secure or upgrade. The clustered broker is Building: it is not in a released version yet.
What happens to my devices when a broker replica fails?
They reconnect to the same address and land on a healthy replica, where a saved session is waiting with its subscriptions and the values kept for it, in order. A value the device was told is in is already stored; a value it was not told about, it still holds and sends again. Their last-will messages wait for them, so a replica going away does not raise false offline alarms.
What does high availability need?
Kubernetes. Every replica of the Unified Namespace service runs the broker, and the replicas share sessions and membership through a NATS JetStream cluster that the chart deploys. You provide the Kubernetes nodes. A single machine runs one broker with no cluster, and its saved sessions start fresh after a restart.
Can I upgrade without stopping the plant?
Yes. Replicas are upgraded one at a time while devices keep publishing, saved sessions outlive the upgrade, and old and new replicas write only what both can read until the last old one is gone.
How do I know it holds up?
You should not take it on trust. In a pilot, kill the replica your devices are on while they publish, then read back what your subscribers received and what the historian stored.
Status: Building. The clustered broker is part of MaestroHub 3.0 and is not in a released version yet. Feature status as of 2026-11-01.
Kill a replica on your own plant.
In a pilot, run the outage drill yourself and read back what your subscribers received. Planning a plant rollout? Ask us for the operator guide: how the cluster behaves on each failure, what each QoS level guarantees, and every setting with its default.