An MQTT broker without compromises: why we built ELX-MQTT Broker
There are plenty of MQTT brokers, and each has its strengths. Yet on a smaller project something is almost always missing: a dashboard, convenient access rights, a simple install. In ELX-MQTT Broker we put together what we missed in the others.
MQTT in brief
MQTT is a lightweight publish–subscribe messaging protocol. A sensor publishes a value to a topic such as home/kitchen/temp, and whoever needs it subscribes to that topic. In the middle sits the broker: it accepts messages, decides who receives them and makes sure nothing is lost on the way.
- QoS 0, 1 and 2 — from fire-and-forget to guaranteed exactly-once delivery.
- Retain — the broker keeps a topic’s last value and hands it to a new subscriber at once.
- Last Will — a message the broker publishes if a client disappears without saying goodbye.
- MQTT 5.0 added reason codes, message expiry, shared subscriptions, topic aliases and flow control.
Smart-home systems, industrial telemetry, trackers, meters and controllers all run on MQTT. The broker is the hub of such a system: if it is awkward or unreliable, everything else suffers.
The kinds of brokers and what they lack
The choice is wide, and the popular brokers have earned their reputation. But each comes at a price:
| Kind of broker | Strength | What you put up with |
|---|---|---|
| Lightweight brokers configured through files | Reliability, a small memory footprint, packaged in every distribution | No built-in dashboard: who is connected and what flows through topics is visible only from the command line; users and rights live in text files |
| Enterprise clustered brokers | Clustering, millions of connections, rich integrations | Heavy for a small site; some features sit in paid editions; installation and setup are a project of their own |
| Cloud brokers | Nothing to install | A subscription fee, message limits, and the site’s data goes to someone else’s cloud |
On automation projects we kept assembling the same thing from several parts: a broker, a separate monitoring dashboard, scripts to create users, an external bridge between sites. That is where the idea came from — a broker that already has all of it.
What we put into ELX-MQTT Broker
ELX-MQTT Broker is a complete MQTT 3.1.1 and 5.0 broker written from scratch in Go, straight from the specification and without third-party protocol libraries. Everything it needs is inside a single executable.
Live web dashboard
Message rate, traffic, clients, the topic tree and an event feed in real time
Topic-level rights
Deny-by-default ACLs; one rule with $u locks every device into its own branch
Bridges
Two-way topic forwarding between brokers with TLS and loop protection
Delayed publish
$delayed/60/topic — delivered a minute later, survives a restart
REST API
Everything the dashboard can do is available with a token, including read-only tokens
A single file
Dashboard, SQLite storage and TLS built in; no Docker, no external database
| Area | What you get |
|---|---|
| Protocol | Full MQTT 3.1.1 and 5.0: QoS 0/1/2, retain, Last Will, persistent sessions, shared subscriptions, reason codes, the AUTH packet |
| Transports | TCP, TLS, MQTT over WebSocket and secure WebSocket |
| Accounts | Built-in list, MariaDB or MySQL, SQLite, CSV, JWT, an external HTTP service |
| Routing | Topic rewriting, automatic subscriptions, bridges |
| Limits | Per-connection token bucket, thinning of chatty sensors by topic pattern |
| Dashboard | Seven interface languages, built-in documentation that works offline |
Speed and connection count
Convenience should not cost performance, so the broker went through load testing on two benches: over a network with a separate load generator, and on a powerful server with no network in between. The headline figures:
| Metric | Result |
|---|---|
| Concurrent connections | 10,000 over the network without a single failure; 30,000 without failures and about 41,000 out of a 50,000 attempt on one machine |
| Ingest, QoS 0 | Up to ≈277,000 messages per second over the network |
| Delivery to subscribers | ≈1.35 million messages per second with fan-out to 100 subscribers |
| Publisher → broker → subscriber latency | Median ≈1 ms over the network, 73 µs without it |
| Robustness | No crashes, hangs or log errors across all runs |
In the tests the ceiling was the load generator and the network, not the broker. That leaves ample headroom for a smart home and for an industrial site with thousands of sensors alike. The full report with the methodology is on the download page.
Runs on many platforms
| System | Builds |
|---|---|
| Windows 10 and 11 | Installer or portable executable |
| Debian, Ubuntu | amd64 — regular servers and PCs |
| Raspberry Pi and other ARM boards | arm64 and armhf |
The broker is written in Go without CGO and needs nothing but itself: no runtime, no Docker, no external database. Retained messages, sessions, queues, users and settings live in one SQLite file — backing up the broker means copying that file.
Completely free
ELX-MQTT Broker is free in full: there is no paid edition that holds back bridges, the dashboard or external account sources, and no limit on the number of devices. Every feature described above is in the build you download.
How to run it
wget https://elxsoftware.com/download/elxmqttbroker-linux-amd64
sudo install -m 755 elxmqttbroker-linux-amd64 /usr/local/bin/elxmqttbroker
sudo elxmqttbroker --install-service
sudo systemctl enable --now elxmqttbrokerOn Windows just run the installer or elxmqttbroker.exe. The dashboard opens at http://<address>:8567, MQTT listens on port 1883 and MQTT over TLS on 8883.
admin / admin so that the first start needs no setup. Change the password before the broker becomes reachable from the network.Step-by-step setup of users, TLS and bridges is in the documentation. And if the data has to come from Modbus devices, have a look at ELX-MODBUS: it publishes straight into this broker.