Skip to main content

MQTT Bridge Overview

The MQTT_BRIDGE connector connects your Coreflux broker to another MQTT broker and keeps selected topics in sync between them. Use it for edge-to-cloud synchronization, linking multiple sites, or mirroring data to a backup broker.
Like call forwarding for messages. You decide which topics get forwarded and in which direction, and the bridge relays every matching message between the two brokers automatically.

When to use it

  • Push local sensor data from an edge device up to a cloud broker.
  • Pull commands or configuration from a central broker down to remote sites.
  • Keep two brokers continuously in sync for redundancy.

Let’s look at how to define a bridge, starting with the most common scenarios.

Quick Start

Forward local sensor data up to a cloud broker over TLS:

Connection Configuration

A bridge has two endpoints: a SOURCE_CONFIG (usually your local broker) and a DESTINATION_CONFIG (the remote broker). Use WITH BROKER SELF for the local Coreflux broker, or provide explicit connection details for a remote one.
string
required
IP address or hostname of the broker. Use SELF for the local broker.
integer
required
MQTT port (typically 1883 for unencrypted, 8883 for TLS).
string
Client identifier for the bridge connection. Optional. When unset, the broker generates one that is unique per host, connector and endpoint (cf-<host>-<connector>-src or cf-<host>-<connector>-dst). Set it when the remote broker expects a specific client ID, and keep it distinct for each connector.
string
Authentication username.
string
Authentication password.
boolean
Enable TLS encryption. Default: false.
boolean
Allow untrusted certificates. Default: false.
string
Path to CA certificate file.
string
Path to client certificate for mTLS.
string
Client certificate password.
integer
Number of reconnection attempts. Default: 5.

Mapping Configuration

Each ADD MAPPING block defines which topics are bridged and in which direction.
string
required
Topic pattern to subscribe to on the source broker. Supports wildcards.
string
required
Topic to publish to on the destination broker.
string
required
Data flow direction: out (source→dest), in (dest→source), or both.

Secure mTLS Bridge

For production links between sites, encrypt both endpoints and authenticate with mutual TLS:

Best Practices

Always enable TLS when connecting to external brokers:
If you set CLIENT_ID, keep it unique per bridge connection to avoid conflicts. Two connections with the same client ID on one remote broker disconnect each other. Leave it unset to use the generated default.
Use WITH BROKER SELF during development:
Store passwords securely and use app-specific passwords where available.
Configure appropriate retry settings:

Troubleshooting

  • Verify IP address and port are correct
  • Check firewall allows outbound connections on the configured port
  • Ensure remote broker is running and accessible
  • Try increasing RECONNECTION_RETRIES
  • Verify certificate paths are correct
  • Ensure certificates are valid and not expired
  • Check certificate chain is complete
  • For testing, use ALLOW_UNTRUSTED_CERTS "true" (not recommended for production)
  • Verify SOURCE_TOPIC and DESTINATION_TOPIC are correct
  • Check DIRECTION setting matches your expected data flow
  • If you set CLIENT_ID, ensure it is unique across all connections
  • Check broker logs for subscription errors

Next Steps

System Connectors

Compare bridging and Sparkplug roles.

Sparkplug B

Publish and consume structured industrial MQTT data.
Last modified on October 22, 2026