Overview
Eclipse Mosquitto is a lightweight open-source MQTT broker maintained by the Eclipse Foundation, written in C, known for its low resource usage and simple deployment. It supports MQTT 3.1.1 and 5.0 protocols, suitable for embedded devices, edge gateways, Raspberry Pi, and small IoT projects. Compared with enterprise-level brokers like EMQX, Mosquitto is more lightweight, with single-machine connections usually below ten thousand, fitting resource-constrained or small to medium-scale scenarios. It supports TLS encryption, username/password authentication, and ACL topic permission control, meeting basic security requirements. It is widely used in smart home, industrial edge, and prototype verification scenarios.
Choosing between Mosquitto and EMQX: Mosquitto is suitable for scenarios with fewer than 10,000 connections, single-machine deployment, and limited resources; EMQX is suitable for million-level connections, clustering, rule engines, and multi-protocol scenarios. Open-source projects like Home Assistant and Node-RED often recommend Mosquitto as the local MQTT broker, forming a 'lightweight local + large-scale cloud' combination with EMQX.
Core Features
Lightweight and cross-platform
Low memory usage, can run on Raspberry Pi, embedded Linux, Windows, macOS. Supports Docker deployment. No additional dependencies, simple installation and configuration. Suitable as a lightweight message hub at the edge or locally.
Protocol and Security
Full support for MQTT 3.1.1 and MQTT 5.0. TLS/SSL encryption, username/password, ACL (topic-based read/write control). Supports anonymous access (configurable to disable). Can connect to external authentication (such as HTTP or MySQL plugins).
Persistence and Bridging
Message persistence, persistent sessions (Clean Session=0), Last Will and Testament (LWT) messages. Supports Broker bridging, allowing local Topics to be forwarded to remote Brokers, achieving a hybrid local + cloud architecture.
Typical IoT Applications
Local Hub for Smart Home: Home Assistant + Mosquitto, devices access via MQTT. Industrial Edge Data Collection: edge gateways embedded with Mosquitto, local devices aggregated and bridged to cloud EMQX. Prototype Verification and Learning: quickly set up an MQTT environment to verify device communication. In IoT solutions, Mosquitto can be chosen as the MQTT broker for edge or small-scale scenarios, working with IoT SIM cards to enable device connectivity and message transmission.
Session and permission boundaries of a single-node broker
What the broker process is responsible for forwarding
In this system Mosquitto is an MQTT broker process. It accepts client connections, forwards publishes to current subscribers by topic, and completes the acknowledgement for this hop according to the quality of service. It stores sessions and a small number of messages that must persist. Business archives and history curves are not kept here. The topic is a routing key, and the payload is opaque to the broker. QoS 0 forwards on a best-effort basis, QoS 1 requires the message to reach the broker at least once, and QoS 2 completes a full handshake between the client and the broker. Those guarantees stop at this hop. Whether the business handles a message only once is decided by the subscriber's own idempotency key.
A persistent session remembers subscriptions after the clean-session flag is turned off, together with acknowledgements that are not finished. A will is published by the broker, on a topic arranged in advance, when the connection is judged to have dropped abnormally. A retained message is the last payload on a topic that carried the retain flag, so a new subscriber receives it as soon as it subscribes. Whether these three pieces of state survive a restart depends on whether the persistence file is enabled. A process that runs only in memory loses its sessions, unacknowledged messages, and retained messages together after a power loss. On site that looks like "the broker is back, but the devices behave as if they were just installed."
Resource conditions when it sits beside a gateway
It fits places where the connection count stays inside what one machine can be watched, the install package must be small, and configuration can be kept as files. On a gateway, an industrial PC, or a small server, gathering field devices into one local topic space and bridging onward only when needed is a sound placement. Someone has to watch concurrent connections, in-flight messages, and the persistence file on disk. A slow subscriber fills the in-flight window, and publishers are then blocked. Plain text, TLS, and WebSocket should use different listeners. Certificate paths and protocol versions belong on the matching listener. Changing one global item does not automatically cover every port.
When many nodes must share the connections, or large-scale rule computation must run inside the broker, leave Mosquitto at the edge or in a test environment and hand the aggregated traffic to a broker designed as a cluster. Placed with Node-RED or Home Assistant, the broker only forwards topics, and the flow or automation hub turns topics into actions. The two sides should not each keep a contradictory set of topic permissions.
Anonymous access, bridge loops, and retained messages
Anonymous access is convenient on a bench. Once the port can be scanned from the field network, publish rights are handed to any client. Before going live, turn anonymous access off, switch to a username and password or a certificate, and use an access-control list to limit read and write by topic prefix. Lists written the wrong way round are common: a device granted subscribe rights on the whole topic tree can hear other devices' uplinks. Give topics a prefix first, then write the rules, so a whole-tree wildcard is not allowed with a plan to tighten it later.
A bridge does not turn two brokers into one cluster. If both ends bridge the same topic to each other and add no prefix, one message is amplified back and forth until disk and bandwidth fill together. Bridge direction, topic filters, and the local prefix should be designed as a pair, and one test message in a test environment should confirm that it appears only once. The retained-message failure mode is an old payload that new subscribers keep treating as the current value: the device has stopped reporting, and the screen still shows a temperature from several hours ago. When a point is retired, publish an empty retained message to clear the old value, or put the sample time in the payload and let the subscriber judge expiry. Mixing clean sessions with persistent sessions drops subscriptions after reconnect, which looks like the broker is online and no data arrives. Check the clean-session flag first, then the network.