A single MQTT broker is a hub where publishers and subscribers meet, but real deployments often have more than one broker: a small broker at each site and a large one in the cloud. Connecting them so that data at a site reaches the central system is the job of a bridge. An MQTT bridge is a special link where one broker acts as a client of another and forwards chosen topics across, in effect stitching two brokers into a larger fabric. This guide explains what a bridge is, how forwarding and topic remapping work, and why the local-broker-to-cloud pattern is so common in field telemetry.
MQTT Bridge in one line: An MQTT bridge is a broker-to-broker connection in which one broker connects to another as a client and forwards a selected set of topics between them. It is most often used to link a local site broker to a central or cloud broker so that messages published at the site flow upstream, optionally with the topic names rewritten as they cross the bridge.
Normally the clients of a broker are edge devices and applications. A bridge is unusual because one of the clients is itself another broker. When a site broker is configured to bridge to a cloud broker, the site broker opens a connection to the cloud broker just as any client would, authenticates, and then either subscribes to topics it wants to pull down or publishes topics it wants to push up. To the cloud broker, the incoming site broker looks like an ordinary well-behaved client, and to the devices at the site nothing changes at all.
This arrangement lets each broker keep doing its local job while a defined slice of traffic crosses between them. Devices at a site publish to their local broker with low latency and no dependence on the wide-area link, and the bridge quietly relays the relevant messages onward. The two brokers remain distinct systems with their own sessions, their own retained messages, and their own subscribers; the bridge only carries the topics it is told to carry, in the direction it is told to carry them.
A bridge can be configured to move data in either or both directions. An upstream-only bridge forwards site telemetry to the cloud but pulls nothing down, which suits pure monitoring. A bidirectional bridge additionally lets the central system push commands or setpoints back down to the site by publishing to a topic the site broker has subscribed to across the bridge. Which topics flow which way is an explicit part of the bridge configuration, not an automatic mirroring of everything.
A bridge is rarely a firehose that copies every topic. Instead it is configured with a set of topic patterns and a direction for each, so that only the traffic that needs to leave the site actually does. A site might forward its measurement topics upward while keeping purely local diagnostic chatter at home, which keeps the wide-area link lean and avoids sending the cloud data it does not need. This selectivity is one of the main reasons a bridge is preferred over simply pointing every device straight at the cloud.
Bridges commonly also remap topics as they cross. A device at a site might publish to a short local topic that means nothing outside that site, and the bridge can prefix or rewrite it so that when it arrives at the cloud broker it carries the site's identity, turning a local name into a globally unique one. This lets each site use simple local naming while the central system sees a clean, namespaced hierarchy in which every site's data lands in its own branch. Remapping in the downstream direction can strip that prefix off again so commands arrive at the site under the local name devices expect.
Because the bridge is a normal client of the remote broker, all the ordinary MQTT mechanics apply to it. It can use a chosen quality-of-service level for the forwarded messages, it can be secured with TLS and credentials like any other connection, and it maintains its own connection state. If the link between the two brokers drops, the bridge behaves like any client that lost its connection, reconnecting when it can, and a well-configured bridge combines this with local buffering so that messages produced during the outage are forwarded once the link returns.
The local-broker-to-cloud bridge is one of the most common architectures in field telemetry, and for good reason. Putting a broker at each site gives devices a nearby, always-available place to publish, so acquisition keeps running at full speed even when the wide-area link is degraded or down. The bridge then carries that data to the central platform whenever the link allows. The site becomes self-sufficient for local operation, and the cloud becomes the aggregation point, without every device having to individually manage a fragile long-haul connection.
This structure pairs naturally with buffering. When the backhaul drops, the site broker and its bridge can hold messages and forward the backlog once connectivity is restored, so a temporary outage produces a delay rather than a gap in the central record. Devices publishing to the local broker are shielded from the outage entirely, since they are talking to something on the same site network. The result is that the wide-area link becomes a place where slowness and interruptions are tolerated rather than a place where data is lost.
For a cloud SCADA platform such as Merobix, the bridge pattern is a clean way to onboard a site that already runs its own broker. The central cloud broker receives a single, authenticated, remapped stream from each site rather than many individual device connections crossing the internet, which simplifies security and naming. Each site's data arrives under its own namespace, ready to be routed into the historian and displays, while local control and acquisition at the site keep running independently of the health of the link to the cloud.
A normal client is a device or application that publishes and subscribes for its own use. A bridge is a connection where one broker acts as a client of another broker specifically to forward topics between the two, joining them into a larger system. The remote broker often cannot tell the difference, because a bridge connects and behaves like any other client, but its purpose is broker-to-broker relaying rather than end-user messaging.
No. A bridge forwards only the topics it is configured to forward, and in the direction specified for each. This selectivity is deliberate, so that local-only traffic stays at the site and only the data that needs to reach the central system crosses the link. Many bridges also rewrite topic names as they cross, for example adding a site prefix upstream and removing it downstream.
A bridge behaves like any client that lost its connection: it stops forwarding and attempts to reconnect when the link is available again. Devices at the site continue publishing to the local broker unaffected. If the site broker or bridge is configured to buffer, the messages produced during the outage are forwarded once the connection is restored, so the outage causes a delay rather than lost data.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.