Self-Hosted IoT Platforms: ThingsBoard, EMQX, Mainflux Compared

Self-hosting an IoT platform stopped being unusual in the late 2010s. In 2026 it is a defensible commercial choice — sometimes the obvious one — for any team with the operational capacity. Here are the platforms worth knowing and when each is the right call.

Why teams self-host in 2026

Three durable reasons:

1. Cost at scale. Above ~100k devices, AWS IoT Core or Azure IoT Hub pricing becomes the largest line in the cloud bill. A self-hosted broker on Kubernetes typically costs 30–60% less at this scale, even accounting for SRE headcount.

2. Data sovereignty. Customer requirements (EU public sector, India DPDP, Australian government) sometimes demand data stays in regions or providers the managed clouds don’t fully offer. Self-hosting lets you pick where everything lives.

3. Protocol flexibility. Custom protocols, AMQP 1.0 with specific features, MQTT 5 features the managed clouds don’t fully expose, or CoAP at scale — all easier on self-hosted than managed.

Rarely worth self-hosting just for “lock-in” reasons; see our multi-cloud IoT post on why that argument usually doesn’t survive scrutiny.

The platforms worth knowing

EMQX (open source + Enterprise)

The default MQTT broker for serious IoT in 2026.

Strengths:

• Best-in-class MQTT 5 support
• Horizontal scaling — millions of concurrent connections per cluster
• Enterprise edition adds clustering with persistent queues, advanced auth (LDAP, JWT, OAuth), and integrations
• Open source core under Apache 2.0 — production-defensible

Limits:

• Pure broker — you build the device registry, application logic, and dashboards yourself
• Dashboard included is operations-focused, not customer-facing

Right when: you need a high-performance MQTT broker and have the application layer covered separately.

ThingsBoard

Closer to a full IoT platform than just a broker.

Strengths:

• Includes device registry, dashboards, rule engine, and alarming out of the box
• Multi-tenancy is a first-class feature — useful for white-label or B2B2C deployments
• Open source Community Edition is genuinely usable; Professional Edition adds advanced features
• Strong ecosystem of integrations and widgets

Limits:

• Performance per node is lower than EMQX for pure MQTT broker workloads
• Dashboard UX is functional, not beautiful — customisation possible but takes work
• Java-heavy stack; expect a JVM-tuning component to operations

Right when: you need an IoT application platform you control end-to-end, with multi-tenancy, and you don’t want to build the dashboard layer yourself.

Mainflux (Magistrala)

Modern microservices IoT platform; the project rebranded as Magistrala in late 2024.

Strengths:

• Cloud-native architecture (Go, gRPC, Postgres, NATS) — operational story that matches modern Kubernetes practice
• MQTT, HTTP, CoAP, WebSocket all first-class
• Apache 2.0 licensed
• Strong fit for teams that want to extend the platform with custom services

Limits:

• Smaller community than EMQX or ThingsBoard
• Documentation good but lighter than the big-name options
• The platform is genuinely modular but you’ll write integration glue

Right when: you want a cloud-native IoT platform you can extend, in a stack you’re comfortable operating.

HiveMQ

Commercial MQTT broker with strong enterprise positioning.

Strengths:

• Excellent MQTT 5 support, particularly QoS 2 and persistent sessions at scale
• Mature commercial support and SLAs
• Extensions ecosystem (Kafka bridge, MongoDB integration, etc.)
• HiveMQ Cloud option for managed hosting if you want hybrid

Limits:

• Commercial-first — open-source community edition exists but enterprise features matter
• More expensive than EMQX Enterprise at comparable scale

Right when: the customer demands commercial-grade SLAs and the budget supports HiveMQ pricing.

Honourable mentions

• VerneMQ — MQTT broker, Erlang-based, mature, niche but solid
• NanoMQ — embedded / edge MQTT broker, runs on resource-constrained gateways
• Mosquitto — Eclipse open-source broker; small-scale or experimental work, not production at IoT scale

How to choose

Walk these questions:

1. Pure broker or full platform?

   • Broker only → EMQX, HiveMQ, NanoMQ, or VerneMQ
   • Full platform → ThingsBoard or Magistrala

2. Open source or commercial?

   • Open source preferred → EMQX OSS, ThingsBoard CE, Magistrala
   • Commercial SLA needed → HiveMQ, EMQX Enterprise, ThingsBoard PE

3. Stack alignment?

   • Java team → ThingsBoard fits; HiveMQ tolerable
   • Erlang/Elixir team → EMQX, VerneMQ
   • Go team → Magistrala, EMQX (configurable)

4. Scale target?

   • 10k devices → most platforms work; pick by team fit
   • 100k devices → EMQX, ThingsBoard PE, HiveMQ at this point
   • 1M+ devices → EMQX Enterprise or HiveMQ; consider sharding ThingsBoard or Magistrala carefully

What self-hosting actually costs

Honest numbers for a 100k-device fleet in 2026:

• Compute: $1,500–$3,500/month for a properly-sized broker tier (3–5 nodes, m5.xlarge-equivalent)
• Storage: $500–$2,000/month for time-series + metadata
• Network egress: highly variable; budget $1,000–$5,000/month
• People: 0.25–0.5 FTE of an SRE familiar with the chosen stack
• Tooling: Datadog, Grafana Cloud, etc. — $500–$1,500/month

Compare to AWS IoT Core or Azure IoT Hub at the same scale (typically $10k–$25k/month all-in, see our IoT cost post). The savings are real but not infinite, and the SRE component is a real cost.

What we typically deploy

For a customer self-hosting in 2026:

• Broker: EMQX Enterprise on EKS or AKS, three-node cluster, persistent volumes for QoS 2 storage
• Time-series: TimescaleDB on managed Postgres
• Application: custom services in the customer’s preferred language (Go, TypeScript, Python)
• Dashboard: Grafana for operations, custom React/Astro for customer-facing
• Observability: Prometheus + Grafana + Loki + Tempo, or Datadog if budget allows
• CI/CD: Argo CD with GitHub Actions; one-click deploy to staging and prod

The total stack is around 12 services. Documented, monitored, and operated, it runs reliably without heroics.

What we hand over

For a self-hosted IoT platform engagement:

• Helm charts for every component, version-pinned
• Operations runbook for every alert
• Disaster recovery plan with tested restore procedure
• Cost projection at 1k, 10k, and 100k devices
• Migration playbook back to managed cloud if requirements change

If you are evaluating self-hosting — or running a self-hosted platform that needs an SRE-aware refactor — we have built and operated this stack across multiple customers.