EMQX
Scalable MQTT broker
Scalable MQTT broker. Connect 100M+ IoT devices in one single cluster, move and process real-time IoT data with 1M msg/s throughput at 1ms latency.
Key features
- Massive MQTT connection scaling
- Built-in clustering
- MQTT 5, WebSocket and CoAP
- Rules engine and data bridges
Pros & cons
Strengths
- Massive connection scaling
- Clustering built in
- Rich protocol support
Trade-offs
- Some features enterprise
- Unfamiliar Erlang stack
EMQX replaces
Last reviewed Sep 13, 2026 · 842 words
EMQX is built to hold 100 million MQTT connections across a cluster and push a million messages a second. Your home automation setup has 40 devices and moves a few hundred messages a minute, which Mosquitto handles on 5 MB of RAM. So the honest verdict up front: most people reading this should run Mosquitto, and EMQX earns its 512 MB minimum only when you want one of three specific things. A web dashboard that shows every client and topic. A rules engine that routes messages somewhere without a bridge script. Or clustering, because a single broker going down is not acceptable.
The dashboard is the feature that sells it at home
Mosquitto is a black box. You know a device is connected because it stopped complaining. EMQX ships a web dashboard on port 18083 (default login admin / public, and it forces a change on first login) that lists every connected client, its IP, its subscriptions and its keepalive, with live message rates per topic. When a Zigbee coordinator drops off the bus at 3 a.m., you find out from the dashboard's client list rather than from a wall of Home Assistant "unavailable" entities. If you have ever tailed mosquitto -v output trying to work out which of 30 ESP boards is spamming a topic, this is the thing you wanted.
Running it: four ports and two volumes
The container is a single image, and the ports matter more than the rest of the compose file:
services:
emqx:
image: emqx/emqx:latest
ports:
- "1883:1883" # MQTT
- "8883:8883" # MQTT over TLS
- "8083:8083" # MQTT over WebSocket
- "18083:18083" # dashboard
volumes:
- ./emqx-data:/opt/emqx/data
- ./emqx-log:/opt/emqx/log
restart: unless-stopped
Idle, expect the Erlang VM to sit at 150 to 300 MB of resident memory before you connect anything, which is the cost of a runtime designed for a million sockets. Anonymous connections are allowed by default. The first job after login is to open Access Control, create a built-in database authenticator, add one user per device or service, and then disable anonymous access. Point Home Assistant and Zigbee2MQTT at port 1883 with those credentials and nothing else about them changes.
The rules engine replaces a folder of scripts
This is where EMQX pulls ahead of every small broker. A rule is a SQL-like statement over incoming messages, such as SELECT payload.temperature AS t FROM "sensors/#" WHERE payload.temperature > 40, with an action attached. In the open-source edition the actions that matter are republish to another topic, a webhook to an HTTP endpoint, and an MQTT bridge to another broker. That covers forwarding filtered sensor data to n8n or to a broker on a VPS without touching a line of Python. The data integrations that write straight into Postgres, Kafka or InfluxDB are enterprise features, and the line between editions has moved more than once, so read the release notes of the tag you pull rather than assuming a listed integration is free. The open-source edition is Apache-2.0; the enterprise one is not.
Clustering is real, and mostly irrelevant at home
Two EMQX nodes on the same LAN discover each other from a static seed list and share the subscription table, so a client connected to node A receives messages published to node B. It works, and it is a large part of why the project has 16,687 stars and a commercial company behind it. But a cluster only protects you if the clients can fail over, and a Tasmota plug has exactly one broker address in its config. At home, a single node under restart: unless-stopped plus a nightly copy of the data directory is the correct amount of resilience. Clustering is for a workshop or small business with hundreds of gateways and a load balancer in front.
Where it is the wrong tool
The Erlang stack is opaque when something goes wrong below the dashboard: the logs are dense, the config file is HOCON rather than Mosquitto's one-option-per-line format, and the community answers on the forum assume you run fleets. Major version upgrades have needed config migration. And if all you want is a broker for the home automation tools on one box, you are paying 300 MB of RAM and a heavier upgrade path for a dashboard you will open twice a year.
What I'd do
Mosquitto for a house. EMQX the moment device count passes a few hundred, or the moment I catch myself writing a second script to copy messages between brokers or into a webhook, because the rules engine pays for the RAM at that point. If I did run it, I would pin a specific version tag, close anonymous access on day one, use the built-in authenticator with one credential per client, keep TLS on 8883 for anything crossing the internet, and leave clustering off until a second physical site exists to justify it.
Similar home automation apps
Home Assistant
Home AutomationOpen-source home automation that puts privacy first
Replaces SmartThings, Google Home
Frigate
Home AutomationLocal NVR with real-time AI object detection
Replaces Google Home
ntfy
Home AutomationSend push notifications to your phone via simple HTTP
Replaces Pushover, Pushbullet
Homebridge
Home AutomationBring non-HomeKit smart devices into Apple Home
Replaces Apple HomeKit hubs
Tasmota
Home AutomationOpen-source firmware for ESP-based smart devices
Replaces Tuya Cloud
ThingsBoard
Home AutomationOpen-source IoT platform for device management and data
Replaces AWS IoT, Azure IoT