VerneMQ

Distributed MQTT infrastructure, honestly reviewed. Written for founders building IoT products, not marketing teams.

TL;DR

• What it is: Open-source (Apache-2.0), distributed MQTT message broker built on Erlang/OTP — designed to handle hundreds of thousands of concurrent device connections with native clustering [README].
• Who it’s for: Engineering teams and founders building IoT platforms, smart product infrastructure, or mobile messaging backends that need proven horizontal scale. This is not a beginner’s tool [1][README].
• Cost savings: Managed MQTT brokers like HiveMQ Enterprise and AWS IoT Core charge at volume — AWS IoT Core starts at $0.08 per million messages and climbs fast. VerneMQ self-hosted on commodity hardware handles the same load for the cost of the server [README].
• Key strength: Native multi-node clustering with automatic failure recovery, built on Erlang/OTP — the same runtime that powers telecom systems designed for “nine nines” uptime. Microsoft, VW, and Arduino appear in their featured users list [website].
• Key weakness: This is infrastructure for engineers. Non-technical setup is not realistic. The Helm chart for Kubernetes has known LevelDB startup issues. Commercial enterprise support pricing is not public [5][README].

---

What is VerneMQ

VerneMQ is a distributed MQTT broker — the central message hub that IoT devices, mobile apps, and backend services talk through. Where a device publishes a sensor reading or a command, VerneMQ routes it to whoever subscribed. It doesn’t store your data, build your dashboards, or manage your fleet. It moves messages reliably between producers and consumers, at scale, across multiple servers.

The project was originally developed by Erlang Solutions and is now maintained as open source under the Apache-2.0 license. It implements MQTT 3.1, 3.1.1, and 5.0 in full [README]. The GitHub description puts it plainly: “A distributed MQTT message broker based on Erlang/OTP. Built for high quality & Industrial use cases.”

The choice of Erlang/OTP is deliberate and consequential. Erlang was built for telecom switches — systems that can’t go down, that handle millions of concurrent lightweight connections, that survive node failures without operator intervention. VerneMQ inherits that architecture. When a node in a VerneMQ cluster goes down, sessions migrate automatically. When a network partition heals, the underlying distributed data store resolves conflicts [website FAQ].

The result is a broker that the website FAQ claims can handle over a million concurrent connections — not by optimizing a single machine, but by adding nodes to a cluster that shares state [website].

As of this review, VerneMQ has 3,546 GitHub stars. That’s modest compared to EMQX (20K+) or Mosquitto, but it reflects the niche: VerneMQ targets industrial and enterprise deployments, not hobbyist projects [4][README].

---

Why people choose it

The sources available for VerneMQ are thinner than for general-purpose tools — this is infrastructure that gets chosen by engineers for technical reasons, not by marketing teams. What the sources do reveal is a consistent pattern.

It shows up when scale and clustering matter. In MQTT broker comparisons, VerneMQ is consistently grouped with the “serious” options — not the hobby tier. An IoT backend guide from a Swiss engineering firm lists VerneMQ alongside RabbitMQ and Mosquitto specifically when discussing production IoT systems that need reliability [2]. A Stack Exchange thread on self-hosted cloud MQTT points to VerneMQ for teams that need more than Mosquitto provides [3].

The Erlang advantage is real, not theoretical. The website FAQ is unusually direct about why the tech choice matters: Erlang/OTP handles netsplits — situations where cluster nodes temporarily can’t reach each other — with automatic conflict resolution and recovery [website]. HiveMQ and MessageSight (IBM), both Java-based alternatives, are specifically called out as lacking this property: “Both brokers are clusterable but lack proper documentation of their failure modes during the presence of network failures” [website]. That’s a pointed criticism from a competitor’s own FAQ.

Apache-2.0 with no commercial restrictions. VerneMQ is fully Apache-2.0, meaning you can embed it in your product, deploy it for customers, or build a managed service on top of it without calling a lawyer [README]. EMQX uses a Business Source License on some components, and HiveMQ’s community edition is functionally capped.

The plugin architecture avoids Erlang lock-in. The FAQ directly addresses the obvious concern — “Do I need to know Erlang to implement a custom plugin?” The answer is no: a built-in Lua scripting engine comes with database drivers for Postgres, MySQL, MongoDB, Redis, and Memcached, and a webhook approach lets you write plugins in any language [website]. That’s a meaningful concession to the reality that most teams deploying this aren’t Erlang shops.

---

Features

Core protocol support:

• MQTT 3.1, 3.1.1, and 5.0 fully implemented [README]
• QoS 0, QoS 1, QoS 2 [README]
• Retained messages, Last Will and Testament [README]
• MQTT 5.0: enhanced auth, message expiry, LWT delay, topic aliases, flow control, request/response, subscription flags [README]

Clustering and availability:

• Multi-node clustering with session migration on failure [README][website]
• Session balancing across nodes [README]
• Automatic conflict resolution on netsplit recovery [website FAQ]
• Cluster status web page [README]

Auth and multi-tenancy:

• File-based auth out of the box [website FAQ]
• Database-backed auth: MongoDB, MySQL, PostgreSQL, Redis, CockroachDB [README]
• Lua plugin engine for custom auth logic without Erlang [website FAQ]
• HTTP webhooks for external auth/authorization [README]
• Full multitenancy [README]
• TLS/SSL encryption, PROXY Protocol v2 [README]

Message handling:

• Offline message storage via LevelDB [README]
• FIFO and LIFO queue modes [README]
• Shared subscriptions [README]
• Message load regulation and shedding for system protection [README]
• Multiple sessions per ClientId [README]
• Real-time MQTT session tracing [README]

Operations:

• HTTP administration API [README]
• $SYS tree for monitoring [README]
• Graphite metrics reporting [README]
• Console, file, and syslog logging [README]
• WebSockets support [README]
• Bridge support (VerneMQ to VerneMQ or other brokers) [README]

Deployment options:

• Docker (old repo: erlio/docker-vernemq, new: vernemq/vernemq) [README]
• Helm chart for Kubernetes [5]
• Binary packages with commercial support [README]

---

Pricing: SaaS vs self-hosted math

VerneMQ the software is free. You deploy it on your own infrastructure, pay for the hardware, and that’s the model [README].

Commercial support is available from the core team, but pricing is not published. You contact them for evaluation, customization, and operations support — standard for enterprise infrastructure [website].

What you’re replacing when you self-host VerneMQ:

AWS IoT Core: $0.08 per million messages, $0.30 per million connection-minutes in some regions. A deployment with 10,000 devices sending a message every 30 seconds generates roughly 28.8 million messages per day. That’s ~$2.30/day in message charges alone — about $70/month — before connection costs.

HiveMQ Cloud: Free tier capped at 100 connections. Their Starter plan is $0.05 per connection per month for up to 1,000 connections ($50/mo), scaling to custom enterprise pricing beyond that. Their Enterprise Server product (comparable to what VerneMQ offers) requires a commercial license — pricing only on request.

CloudMQTT (now defunct/acquired): Was common for small deployments; its disappearance is exactly why self-hosting a broker like VerneMQ matters for production workloads.

Self-hosted VerneMQ math:

A single VerneMQ node on a 4-core, 8GB VPS (Hetzner CX32 or equivalent) costs roughly $10–15/month and handles tens of thousands of concurrent connections comfortably. A 3-node cluster for high availability runs $30–45/month in hardware. For 10,000 devices, that’s the entire broker cost — versus $50–$200/month on managed MQTT cloud at comparable connection counts.

At 100,000 devices, managed MQTT cloud options start quoting custom enterprise pricing. A VerneMQ cluster at that scale runs on perhaps $100–200/month of commodity hardware. The savings are real, but so is the operational burden.

---

Deployment reality check

The official path is Docker. The README points to binary packages and a Docker image on Docker Hub [README]. The Helm chart exists for Kubernetes deployments.

What works:

• Docker single-node deployment is straightforward
• File-based auth for development is built-in — no database required to get started
• The Lua scripting layer means custom auth logic is achievable without Erlang expertise
• WebSockets and TLS configuration are documented

What doesn’t:

The Kubernetes Helm deployment has documented issues. A Server Fault thread from a real deployment [5] shows a specific crash pattern — the LevelDB storage engine (vmq_generic_msg_store) fails to start, triggered by a badmatch error in vmq_storage_engine_leveldb.erl. The error trace is deep in Erlang internals and not particularly actionable if you don’t read Erlang. The thread is from a few years ago, but the fact that it exists and has 554 views suggests it’s not a rare edge case.

What you actually need for a production deployment:

• A Linux server with 4+ GB RAM per node for non-trivial deployments
• Basic Erlang operational awareness (reading crash logs requires it, even if you don’t write Erlang)
• Reverse proxy (nginx or HAProxy) for TLS termination if not using VerneMQ’s native TLS
• A database (PostgreSQL or Redis) if you want auth beyond flat files
• Understanding of MQTT-specific concepts: QoS levels, session persistence, retained messages, LWT

Realistic time estimate:

• Technical team familiar with Docker and MQTT: 2–4 hours for a working single node
• Multi-node cluster with auth against PostgreSQL: a day or more for a first deployment
• Production-grade Kubernetes cluster with monitoring: multiple days of engineering time
• Non-technical founder: don’t attempt this without engineering help

The FAQ’s claim that “you don’t need to know anything about Erlang” is true for normal operation but optimistic for debugging failures. When something breaks, you’ll see Erlang crash reports [5].

---

Pros and Cons

Pros

• Apache-2.0 with zero commercial restrictions. Embed in your product, deploy for customers, build a managed service — the license doesn’t stop any of it [README].
• Native multi-node clustering with Erlang fault tolerance. This is genuinely harder to build correctly than it looks — VerneMQ gets it from the Erlang/OTP runtime, not bolted-on afterthought clustering [website FAQ].
• Handles netsplits properly. The explicit callout that competing Java-based brokers lack documented netsplit behavior is notable and honest [website FAQ].
• Plugin architecture without Erlang lock-in. Lua scripting with database drivers, plus HTTP webhooks — most teams never need to write Erlang [website FAQ].
• Full MQTT 5.0 support. Not all brokers have caught up; VerneMQ implements all property types and MQTT 5.0 features [README].
• Battle-tested at scale. Microsoft, Volkswagen, and Arduino are listed as featured users — not the typical OSS vanity logos [website].
• Full multitenancy. Useful for platform builders serving multiple customers from a single cluster [README].

Cons

• Not a beginner tool. You need to understand MQTT deeply to configure VerneMQ well. Authentication, QoS trade-offs, session persistence, clustering topology — these require engineering time [website FAQ].
• Helm deployment has known instability. The LevelDB crash on Kubernetes startup is a documented real-world failure [5]. Whether it’s fixed in current releases is unclear from available sources.
• 3,546 GitHub stars is modest. EMQX is at 20K+ stars and has a significantly larger community, more integrations, and better-resourced documentation [4][README]. VerneMQ’s community is smaller.
• Commercial support pricing is opaque. No public pricing page for enterprise support. For a production deployment you’re betting on, not knowing support costs in advance is friction [website].
• Erlang crash logs are hard to read. When things break, the error traces are not friendly to non-Erlang engineers [5].
• Documentation exists but lacks depth. The README points to docs.vernemq.com without much inline guidance. Third-party tutorials are scarce compared to Mosquitto or EMQX [1][3].
• Limited dashboard UI. The built-in monitoring is $SYS tree and a cluster status web page — not a full operational dashboard. Graphite integration exists but requires external setup [README].

---

Who should use this / who shouldn’t

Use VerneMQ if:

• You’re building a product where MQTT is a core infrastructure component — IoT platforms, smart device fleets, M2M systems, industrial automation [README][website].
• You have or will have tens of thousands of concurrent device connections and need real clustering, not a single broker with a standby [website FAQ].
• You want Apache-2.0 licensing without the commercial use restrictions that EMQX’s BSL and HiveMQ’s licensing impose [README].
• Your team includes engineers who can read an Erlang crash report when something breaks.
• You want to avoid AWS IoT Core or HiveMQ cloud costs at scale and are comfortable operating your own infrastructure.

Don’t use VerneMQ if:

• You’re a non-technical founder looking for something you can deploy yourself in an afternoon. This is not that [5][website FAQ].
• Your MQTT needs are simple — a single device, a home automation hobby project, fewer than a few hundred connections. Mosquitto is free, simpler to operate, and sufficient [1].
• You’re evaluating MQTT as a message queue for internal microservices rather than device connectivity. RabbitMQ with its MQTT plugin or even Redis pub/sub is a better fit for pure application messaging [1][2].
• You need a managed solution with a support SLA you can show to your board. Use HiveMQ Cloud or AWS IoT Core, and pay for it.
• Your team is unfamiliar with MQTT protocol specifics. The tool won’t teach you the protocol — it expects you to already know it.

---

Alternatives worth considering

• Mosquitto (Eclipse) — The lightweight, single-node MQTT broker. No clustering, but zero complexity for small deployments. Free, EPL/EDL licensed, massively documented. Start here for anything under a few thousand connections [1][3].
• EMQX — The scale competitor. 20K+ GitHub stars, a richer UI, a hosted cloud option, and a larger ecosystem. Uses Business Source License on some components — read it before embedding in a product. Better documentation and community than VerneMQ [4].
• HiveMQ — The commercial option. Java-based, enterprise features, formally supported SLA. Community edition is capped at 25 connections. The serious commercial alternative when budget allows [1][4].
• RabbitMQ with MQTT plugin — If you already run RabbitMQ for application messaging, its MQTT plugin handles device connectivity without adding a separate broker. Not purpose-built for MQTT scale, but good for mixed workloads [2].
• AWS IoT Core / Azure IoT Hub — Managed cloud options. Zero infrastructure to run; pays per message/connection. Makes sense early in a product when you don’t yet know your scale; becomes expensive and vendor-locked as you grow [3].
• EMQX Cloud — EMQX’s managed hosted option. If you want EMQX’s feature set without self-hosting, this is the path [4].

For a founder building a new IoT product today, the realistic shortlist is VerneMQ vs EMQX for self-hosted, and HiveMQ Cloud vs AWS IoT Core for managed. VerneMQ’s advantage over EMQX is the cleaner Apache-2.0 license. EMQX’s advantage is the larger community and more polished operations story. If you don’t know which you need yet, start with Mosquitto and migrate when you outgrow it.

---

Bottom line

VerneMQ is honest about what it is: industrial-grade MQTT infrastructure for teams that need clustering, fault tolerance, and scale they control. It’s not an easy entry point and doesn’t pretend to be. The Erlang/OTP foundation is a genuine technical advantage for high-availability deployments — the same reason Erlang still runs a meaningful chunk of the world’s telecom infrastructure. The Apache-2.0 license is clean and uncommon at this capability tier.

The people who should be looking at VerneMQ are engineering teams at companies building connected product platforms — the kind where device connections are a core business metric, not an afterthought. If that describes you, and you’re currently paying AWS IoT Core or HiveMQ rates at any meaningful device count, the math for self-hosting is straightforward.

If you’re a non-technical founder who heard “self-hosted MQTT broker” and landed here, the honest recommendation is to start with Mosquitto, learn the protocol, and reach for VerneMQ when you can read an Erlang crash log without calling for help. If getting to production-grade MQTT infrastructure is the blocker, that’s the kind of setup upready.dev handles as a one-time engagement.

---

Sources

1. Engineers Garage — “MQTT Brokers: IoT Part 15”. https://www.engineersgarage.com/mqtt-brokers-iot-part-15/
2. Solcept AG — “IoT Backend für Ihre Produkte” (IoT backend platform overview, German). https://www.solcept.ch/de/plattformen/iot/iot-backend/
3. IoT Stack Exchange — “Cloud MQTT broker” (community Q&A). https://iot.stackexchange.com/questions/4489/cloud-mqtt-broker
4. SaaSHub — “EMQX Alternatives & Competitors” (includes VerneMQ comparison). https://www.saashub.com/emqx-alternatives
5. Server Fault — “Pod using Vernemq helm package cannot start” (Kubernetes LevelDB crash thread). https://serverfault.com/questions/1021959/pod-using-vernemq-helm-package-cannot-start

Primary sources:

• GitHub repository and README: https://github.com/vernemq/vernemq (3,546 stars, Apache-2.0)
• Official website: https://vernemq.com
• Docker Hub (new): https://hub.docker.com/r/vernemq/vernemq