Skip to main content

​
Build the broker topology around your data

System Routes define how your Coreflux broker participates in a wider MQTT system. Use them to bridge selected topics to another broker, or make Coreflux consume and produce Sparkplug B traffic.
Think of System Routes as the roads around the broker. Bridges connect MQTT brokers, and Sparkplug routes define how industrial MQTT traffic enters and leaves the system.
For high-availability Coreflux clustering (multi-node broker failover), see High-Availability Clustering. That feature is broker configuration, not a System Route.

​
When to use System Routes

Use this category when you need to:
  • synchronize topics with another MQTT broker;
  • decode Sparkplug B payloads into readable JSON;
  • publish as a Sparkplug edge node; or
  • make Coreflux the Sparkplug Primary Host Application.

​
Choose a System Route

MQTT Bridge

Synchronize selected MQTT topics with another broker.

Sparkplug B

Decode Sparkplug traffic or publish Coreflux metrics as an edge node.

Sparkplug Host

Make Coreflux the Primary Host for a Sparkplug namespace.
Choose the route by the role Coreflux needs to play.

​
Compare System Routes

A SPARKPLUG_HOST route and a SPARKPLUG_B route in DECODE or BOTH mode cannot run together on the same broker. Both consume the complete spBv1.0/# namespace. You can combine one Host route with separate ENCODE-only routes.

​
Next Steps

Choose a Sparkplug role

Compare decode, edge-node, and Primary Host responsibilities.

High-Availability Clustering

Run multiple Coreflux brokers as a fault-tolerant cluster.
Last modified on August 28, 2026