Eclipse Mosquitto

What is Eclipse Mosquitto?

Mosquitto is the message broker most home automation stacks are built on. Devices publish state and subscribe to commands through it, which decouples your sensors from your automation logic entirely.

Best for

The messaging backbone between devices and automation

Why choose Eclipse Mosquitto

Mosquitto is the message broker that most self-hosted smart home stacks are built on, and its role is to remove direct dependencies between devices and logic. Sensors publish to a topic; automations subscribe; neither needs to know the other exists. That decoupling is what lets you swap a device or rewrite an automation without touching the other side. It is small, it is stable enough to run for years without attention, and it implements MQTT well enough that almost all smart home software assumes it. Because it is a dumb broker, it also serves as a general integration point for anything you write yourself that needs to publish or subscribe, which makes it more broadly useful than its smart home reputation suggests.

Replaces

• HiveMQ Cloud
• AWS IoT Core
• CloudMQTT

Key features

• MQTT 3.1, 3.1.1 and 5.0
• TLS, authentication and topic ACLs
• Bridges to other brokers
• Extremely small footprint

What to watch out for

The default configuration allows anonymous access, and a misconfigured broker reachable from the internet is one of the classic ways a home network is compromised — this is the single most important thing to get right. There is no built-in persistence guarantee by default, so messages published while a subscriber is offline are lost unless you deliberately configure retained messages or persistence. Topic design is entirely your responsibility, and a careless hierarchy becomes impossible to reason about once devices multiply. There is no authentication system beyond username and password or certificates, so access control is per-topic rules you write yourself. Debugging what is actually flowing requires a separate client to subscribe and watch.

How to deploy

• Docker or package manager
• Configure listeners, auth and ACLs
• Enable TLS before exposing it

Getting started

Configure authentication and disable anonymous access before the broker is reachable by anything but localhost, and never expose the port to the internet. Design your topic hierarchy early — typically a base prefix, then location, then device, then attribute — because restructuring topics later means updating every consumer. Enable persistence so messages survive a restart, and use retained messages deliberately for state values clients need on connect. Set up per-user topic access so one compromised device cannot publish to everything. Subscribe with a client and watch the traffic while you configure your first device, because seeing the messages is how you confirm the design is right.

Typical setup

A small service with authentication enabled and anonymous access disabled before it is reachable by anything but localhost, and never exposed to the internet — an open broker is one of the classic ways a home network is compromised. The topic hierarchy is designed early, typically base prefix then location then device then attribute, because restructuring later means updating every consumer. Persistence is enabled so messages survive a restart, and retained messages are used deliberately for state. Per-user topic access restricts what a compromised device can publish to, and a client is subscribed during setup to confirm messages look as expected.

Who should look elsewhere

Do not run it as a public broker without a deep understanding of its access control, because anonymous access and internet exposure together are a serious combination. Avoid it if you need guaranteed delivery, ordering across many topics or message replay for offline consumers — MQTT at this level of quality of service is best-effort. And if you have exactly one device talking to one automation with no plans to grow, a direct connection avoids a broker you would otherwise maintain for no benefit.

Project health

• GitHub stars: 11,238
• Last code push: 2026-09-03
• Open issues: 895
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.