FluxMQ

High-performance multi-protocol message broker.

Open source, high-throughput, low-latency, and scalable. MQTT, AMQP, CoAP, and WebSocket in a single Go binary with no external dependencies.

Open Source · Apache 2.0
300K+
Messages / sec / node
<10ms
Local latency
1 binary
Zero external dependencies
Features

Built for throughput and durability.

Every performance decision in FluxMQ is deliberate, from zero-copy parsing to trie-based topic routing and Raft-replicated durable queues.

🌐
Multi-Protocol Support

Full MQTT 3.1.1 and 5.0 over TCP and WebSocket, plus HTTP-MQTT and CoAP bridges. AMQP 0.9.1 and AMQP 1.0 servers included. All protocols share the same broker core; messages flow seamlessly across transports.

💾
Durable Queues

Persistent message queues with consumer groups, ack/nack/reject semantics, dead-letter queues, and Kafka-style retention. Raft-based replication with automatic failover.

🖥️
Clustering & High Availability

Embedded etcd for coordination, gRPC-based inter-broker communication with mTLS, automatic session ownership, and graceful shutdown with session transfer. No external dependencies.

Performance Optimized

Zero-copy packet parsing, object pooling, and efficient trie-based topic matching. 300K–500K msg/s per node with sub-10ms local latency and up to 500K concurrent connections.

🛡️
Security

TLS/mTLS for client connections, mTLS for inter-broker gRPC, DTLS/mDTLS for CoAP, WebSocket origin validation, and per-IP/per-client rate limiting.

🔧
Open-Source & Extensible

Apache 2.0 licensed with a clean layered architecture: Transport → Protocol → Domain. Pluggable storage backends, protocol-agnostic domain logic, and straightforward extensibility.

Architecture

Layered. Transport → Protocol → Domain.

A clean separation between transports, protocol handlers, and the domain layer makes FluxMQ easy to extend without touching the core.

graph TD
    A[Setup and configuration] --> B["MQTT / WS / HTTP / CoAP
Servers"] A --> C["AMQP 1.0
Server"] A --> D["AMQP 0.9.1
Server"] B --> E["MQTT v3.1.1 / v5 Broker"] C --> F["AMQP Broker 1.0"] D --> G["AMQP Broker 0.9.1"] E --> H["Queue Manager
Bindings + Delivery"] F --> H G --> H H --> I["Log Storage
+ Topic Index"] style A fill:#2a2a2a,color:#f6f4ee,stroke:#444 style B fill:#383a40,color:#f6f4ee,stroke:#383a40 style C fill:#383a40,color:#f6f4ee,stroke:#383a40 style D fill:#383a40,color:#f6f4ee,stroke:#383a40 style E fill:#4a4c52,color:#f6f4ee,stroke:#4a4c52 style F fill:#4a4c52,color:#f6f4ee,stroke:#4a4c52 style G fill:#4a4c52,color:#f6f4ee,stroke:#4a4c52 style H fill:#6c6e73,color:#f6f4ee,stroke:#6c6e73 style I fill:#a4a6ac,color:#14161a,stroke:#a4a6ac

Key Components

  • Transport Layer: Multi-protocol servers: MQTT over TCP and WebSocket, AMQP 1.0, AMQP 0.9.1, CoAP, HTTP, and WebSocket bridges.
  • Protocol Brokers: FSM-based protocol handlers with zero-copy parsing. Session ownership tracked per broker node.
  • Queue Manager: Durable queue bindings with FIFO, priority, and topic-based delivery. Consumer groups, ack semantics, and dead-letter queues.
  • Storage: Pluggable persistence layer for message storage and topic indexing. Raft-based replication across cluster nodes.
How it works

Drop in. Connect. Scale.

01

Drop in the binary

Download the single binary. No external dependencies. Configure TLS, listeners, storage, and cluster peers in one YAML file.

02

Connect your clients

Any MQTT 3.1.1 or 5.0 client, AMQP client, or CoAP device connects immediately. HTTP and WebSocket bridges are built in.

03

Scale horizontally

Add nodes to the cluster. etcd handles coordination. Session ownership transfers automatically. Throughput scales linearly with each node.

Quick Start

Up and running in minutes.

Defaults: MQTT TCP on :1883, AMQP 0.9.1 on :5682, data at /tmp/fluxmq/data.

1. Run with Docker
git clone https://github.com/absmach/fluxmq.git
cd fluxmq
docker compose -f deployments/docker/compose.yaml up -d
2. Test with MQTT
# Subscribe to all topics
mosquitto_sub -p 1883 -t "test/#" -v

# Publish a message
mosquitto_pub -p 1883 -t "test/hello" -m "Hello FluxMQ"
3. Or build locally
git clone https://github.com/absmach/fluxmq.git
cd fluxmq
make build
./build/fluxmq --config examples/no-cluster.yaml
Explore examples on GitHub ↗ Read the docs ↗
Use Cases

Where FluxMQ fits.

Event-Driven Systems

Decouple microservices with durable event streams and reliable CQRS pipelines.

  • → Decouple microservices with event streams
  • → Reliable command & event pipelines (CQRS)
  • → Background jobs & async workflows
  • → Real-time data processing pipelines
MicroservicesCQRSAsync
📡

IoT & Real-Time

Handle device telemetry, edge deployments, and live dashboard updates at scale.

  • → IoT device telemetry ingestion (MQTT)
  • → Edge deployments with intermittent connectivity
  • → Live dashboards & browser updates (WebSocket)
  • → Constrained devices via protocol bridges
TelemetryEdgeWebSocket
📊

High-Throughput Pipelines

Stream millions of events per second with burst buffering and ingestion decoupling.

  • → Stream millions of events per second
  • → Buffer traffic bursts with durable queues
  • → Decouple ingestion from downstream processing
  • → Power analytics & observability streams
StreamingBurstAnalytics
Performance

Numbers that hold up under load.

Benchmarked on commodity hardware. Scales linearly as you add nodes to the cluster with topic sharding.

Single node

300K–500K msg/s

Sustained throughput per node with sub-10ms local latency and up to 500,000 concurrent connections.

  • Zero-copy packet parsing
  • Trie-based topic matching
  • Object pool recycling
  • Session takeover <100ms
3-node cluster

1–2M msg/s

Three nodes coordinated by embedded etcd with gRPC inter-broker routing and mTLS encryption.

  • ~5ms cross-node latency
  • Automatic rebalancing
  • Zero-config cluster join
5-node cluster

2–4M msg/s

Linear throughput scaling with node count. Persistent queues maintain durability guarantees at every tier.

  • Consumer group offsets
  • Dead-letter queues
  • Kafka-style retention
FAQ

Common questions.

How does FluxMQ compare to Mosquitto or EMQX?

FluxMQ is designed for high-throughput, distributed deployments with built-in clustering, durable queues, consumer groups, and AMQP support. Mosquitto is a lightweight single-node MQTT broker. EMQX is a commercial broker with a similar feature set; FluxMQ is fully open source under Apache 2.0 with no commercial restrictions.

Which protocols does FluxMQ support?

FluxMQ supports MQTT 3.1.1 and 5.0 over TCP and WebSocket, AMQP 0.9.1, AMQP 1.0, CoAP (with DTLS/mDTLS), and HTTP-MQTT bridges. All protocols route through the same broker core and Queue Manager.

Does FluxMQ support MQTT 5.0?

Yes. FluxMQ implements full MQTT 3.1.1 and 5.0 over TCP and WebSocket. MQTT 5.0 features including shared subscriptions, flow control, and user properties are supported.

How do I set up a cluster?

FluxMQ uses embedded etcd for cluster coordination. Add a node to the cluster config, point it at the existing members, and it joins automatically. gRPC handles inter-broker message routing with mTLS. Session ownership transfers gracefully when nodes join or leave.

What persistence model does FluxMQ use?

FluxMQ uses a pluggable storage backend for message persistence and topic indexing. The queue layer supports durable queues with configurable retention, dead-letter queues, and consumer group offsets similar to Kafka, with Raft-based replication across cluster nodes.

How does FluxMQ integrate with Magistrala?

FluxMQ is the recommended message broker for Magistrala deployments. It handles the data plane, routing device telemetry through durable queues, while Magistrala provides device identity, RBAC, dashboards, and platform services.

Get started

Drop in FluxMQ today.

Download the binary, read the documentation, or explore the source on GitHub.