FluxMQ

High-Throughput MQTT & AMQP Broker. One Binary, Zero Dependencies.

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

300K+
Messages / sec / node
<10ms
Local latency
Open-source license
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:#073763,color:#f6f4ee,stroke:#073763 style B fill:#1e3a5a,color:#f6f4ee,stroke:#1e3a5a style C fill:#1e3a5a,color:#f6f4ee,stroke:#1e3a5a style D fill:#1e3a5a,color:#f6f4ee,stroke:#1e3a5a style E fill:#4a6a87,color:#f6f4ee,stroke:#4a6a87 style F fill:#4a6a87,color:#f6f4ee,stroke:#4a6a87 style G fill:#4a6a87,color:#f6f4ee,stroke:#4a6a87 style H fill:#ff7a4a,color:#f6f4ee,stroke:#ff7a4a style I fill:#ffeee6,color:#073763,stroke:#ffeee6

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
Contact Sales for enterprise deployments →
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.

How does FluxMQ compare to Apache Kafka?

Kafka is a log-based streaming platform built for high-throughput batch analytics with long-term retention and consumer group replay. FluxMQ is a real-time message broker optimized for IoT and event-driven microservices — lower latency, native MQTT and AMQP wire-protocol support for device firmware, and no ZooKeeper or schema registry required. FluxMQ includes Kafka-style retention and consumer groups for hybrid workloads, packaged as a single binary with zero external dependencies.

How does FluxMQ compare to NATS?

NATS is a lightweight, cloud-native messaging system with excellent core performance. FluxMQ is focused on IoT use cases where MQTT 3.1.1/5.0 and AMQP wire-protocol compliance is required — connecting off-the-shelf device firmware without adapters or proxies. FluxMQ also ships durable queues, consumer group offsets, and dead-letter queues out of the box. Both share the single-binary, zero-dependency operational model.

How does FluxMQ compare to RabbitMQ?

RabbitMQ is a mature AMQP 0.9.1 broker with a rich plugin ecosystem. FluxMQ supports AMQP 0.9.1 and AMQP 1.0 alongside full MQTT 5.0, CoAP, and WebSocket — all in one Go binary with no Erlang runtime or external dependencies needed. FluxMQ targets IoT scale: 500K+ concurrent connections per node and 300K–500K msg/s. RabbitMQ suits complex enterprise routing topologies; FluxMQ is optimized for device-to-cloud pipelines at scale.

Get started

Drop in FluxMQ today.

FluxMQ is the recommended message broker for Magistrala IoT platform deployments. Download the binary, read the documentation, or explore the source on GitHub.