# Eclipse Mosquitto: the MQTT broker you can run with one command

> Mosquitto implements MQTT 5.0, 3.1.1 and 3.1, ships a C/C++ client library and command line tools, and starts as a broker with a single word. Here is how it installs, how the pieces fit, and where it stops being the right choice.

**eclipse-mosquitto/mosquitto** — Eclipse Mosquitto - An open source MQTT broker

- Repository: https://github.com/eclipse-mosquitto/mosquitto
- Website: https://mosquitto.org
- Stars: 11,217 · Forks: 2,645
- Language: C
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/eclipse-mosquitto-mosquitto

## What Mosquitto is, and who ends up running it

Mosquitto is an open source implementation of a server for version 5.0, 3.1.1 and 3.1 of the MQTT protocol. That sentence from the README is the whole product description, and it is worth taking literally: this is a broker, not an IoT platform. It moves messages between clients that publish to topics and clients that subscribe to them, and it does nothing else on your behalf.

The audience follows from that. If you have sensors, gateways, or small devices that speak MQTT and you need something in the middle to receive and fan out their messages, Mosquitto is the middle. The repository also ships a C and C++ client library, so the same project covers both ends: an application links against libmosquitto rather than pulling in a separate MQTT library. Alongside the library live the mosquitto_pub, mosquitto_rr and mosquitto_sub utilities, plus mosquitto_ctrl, mosquitto_signal and mosquitto_passwd for administering the broker.

What it is not: a queue with durable consumer offsets, a schema registry, or a rules engine. If your problem is coordinating microservices with replayable streams, MQTT's topic model is a poor fit and you will spend your time working around it.

## The pieces in the repository and how a message actually moves

The top level layout is unusually explicit about the architecture. src/ holds the broker itself, lib/ holds the client library, libcommon/ and common/ hold code shared between them, client/ holds the command line tools, and plugins/ holds the broker's extension points. apps/ contains the administration applications. This split matters when you build from source, because DIRS in the Makefile walks libcommon, lib, apps, client, plugins and src in that order.

The data flow is the MQTT model applied to those directories. A publisher connects to the broker's listener, sends a PUBLISH packet on a topic, and the broker matches that topic against its subscription tree. Every matching subscriber gets a copy. The broker holds that tree in memory; the sqlite3 dependency exists for persistence support in the broker, and the README lists it as optional, disabled with WITH_SQLITE=no. So a default build keeps state in memory and a build without sqlite keeps it there permanently.

Two extension mechanisms are visible in the layout. The dynamic security plugin is named in the README as the modern way to manage authentication, and the plugins/ directory is where broker plugins live. Separately, libmicrohttpd backs broker HTTP API support and can be turned off with WITH_HTTP_API=no. Both are compile time decisions, which means two Mosquitto binaries from two distributions can behave differently with the same configuration file.

## Installing Mosquitto and publishing your first message

The README does not give package commands. It points at https://mosquitto.org/download/ for binaries on various platforms, and that page is the place to start. If a binary package is installed, the broker is usually started automatically by the system service. If it is not running, the README's basic invocation is a single word with no configuration file:

```bash
mosquitto
```

With that broker running, subscribe in one terminal. The -t flag sets the topic and -v makes the output print the topic alongside the payload:

```bash
mosquitto_sub -t 'test/topic' -v
```

Then publish from another terminal. The -m flag carries the message body:

```bash
mosquitto_pub -t 'test/topic' -m 'hello world'
```

The subscriber prints test/topic hello world. Be clear about what you have just built: the README states that starting the broker this way allows anonymous, unauthenticated access but only from the local computer, so it is useful for initial testing and nothing more. The moment a client on another machine needs to connect, you need a configuration file. Binary packages typically place one at something like /etc/mosquitto/mosquitto.conf; a source build is started with mosquitto -c /path/to/mosquitto.conf.

The README's guidance for that file is to define a listener and then decide what authentication you require, and it states plainly that running the broker with anonymous access on a public interface is not advised. It links to the authentication methods page and the dynamic security plugin rather than inlining the directives, so the actual listener and auth options come from the man pages at https://mosquitto.org/man/. On Windows and Mac the README directs you to cmake; on other platforms make is the path, and make binary skips building the man pages.

## Where Mosquitto is the wrong tool

The most common mistake is treating the anonymous local default as a deployment. It is a test mode. Anything reachable from another host needs a listener plus an authentication decision, and the README does not soften that.

The second limitation is build variability. TLS is optional and disabled with WITH_TLS=no. SRV lookup is optional and enabled with WITH_SRV=yes. The HTTP API is optional. sqlite persistence is optional. If you install a stripped binary and then wonder why a configuration directive does nothing, the answer may be that the feature was never compiled in. The README documents the switches for source builds and notes that equivalent options exist for the CMake build, but it does not tell you how to inspect an already installed binary for them.

Thread safety is the third. The README states that pthreads are required to support mosquitto_loop_start() and mosquitto_loop_stop(), and that if the library is compiled without pthread support it is not guaranteed to be thread safe. That is a build time property of the library you link against, and it is easy to miss when moving between platforms.

Finally, scale. Nothing in the README makes a capacity claim, and there is no clustering story in the documentation. If you need a broker that survives the loss of a node without external coordination, Mosquitto is not presenting itself as that product.

## Building from source, vcpkg, and what the licence files imply

For source builds the README recommends downloading the archive from https://mosquitto.org/download/ rather than building from the git repository, because in a git checkout the documentation is not pre-built and you need docbook-xsl (xsltproc and docbook-xsl on Debian based systems) unless you use make binary or set WITH_DOCS=no. Dependencies are listed explicitly: cJSON is required; c-ares, libedit, libmicrohttpd, openssl, sqlite3 and xsltproc are optional; uthash and utlist are bundled and can be disabled with WITH_BUNDLED_DEPS=no.

There is also a vcpkg route, which pulls the port from Microsoft's registry:

```bash
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install mosquitto
```

The README notes that the vcpkg port is kept up to date by Microsoft team members and community contributors, and that an out of date version should be raised as an issue or pull request on the vcpkg repository rather than here. That is a real maintenance consideration: the version you get through vcpkg is a separate moving part from the upstream project.

On licensing, the repository carries LICENSE.txt, NOTICE.md, edl-v10 and epl-v20 at the top level, and the project metadata does not resolve to a single SPDX identifier. Two licence texts plus a notice file means the terms are worth reading directly rather than inferring from a topic tag. I am not in a position to tell you what they permit for your distribution; read LICENSE.txt and NOTICE.md and decide with whoever handles that at your organisation.

## Mosquitto against a general purpose message broker

The natural alternative is a broker built for application backends rather than constrained devices, and RabbitMQ is the usual comparison. The difference is in the model, not the feature list. RabbitMQ routes through exchanges and queues with acknowledgements and consumer offsets, so a consumer that was offline can resume where it left off, and the broker is designed to be clustered. Mosquitto routes through a topic tree over MQTT, keeps that tree in memory by default, and its persistence support is an optional sqlite3 build feature rather than the core abstraction.

That makes the trade explicit. Mosquitto is small, written in C, and speaks one protocol with three revisions plus a client library that ships in the same repository, so a device with modest resources can talk to it directly. RabbitMQ expects more from the client and from the operator, and gives you durable queues and clustering in return. If your devices are the constraint, pick Mosquitto. If your consumers need replay after downtime, pick the other one, because Mosquitto will not give you that by default. For those who want a hosted endpoint to test against before installing anything, the README points at the public test server at https://test.mosquitto.org/.

## Conclusion

Adopt Mosquitto if you need a small MQTT broker you can start with the mosquitto command, drive from mosquitto_pub and mosquitto_sub, and embed through the C/C++ client library. Do not adopt it as a general purpose message bus, and do not run it with anonymous access on a public interface. Before committing, verify which optional features your build actually has, because TLS, the HTTP API, sqlite persistence and SRV lookup are all compile time options that can be switched off, and check the licence terms in LICENSE.txt, NOTICE.md, edl-v10 and epl-v20 against your own distribution model.

## FAQ

### What is Eclipse Mosquitto used for?

It is used as an MQTT broker: it receives messages published to topics and delivers them to subscribers. The repository also provides a C and C++ client library and the mosquitto_pub, mosquitto_rr and mosquitto_sub utilities, so the same project covers both the server and the client side.

### What is the difference between MQTT and Mosquitto?

MQTT is the protocol; Mosquitto is an open source implementation of a server for version 5.0, 3.1.1 and 3.1 of that protocol. The README links to the OASIS standards for MQTT and describes Mosquitto as the server implementation plus client library and utilities.

### Is Mosquitto an MQTT server?

Yes. The README describes Mosquitto as an open source implementation of a server for MQTT versions 5.0, 3.1.1 and 3.1, and the broker is started with the mosquitto command.

### Can I use MQTT on Windows with Mosquitto?

The README says to use cmake to build on Windows and Mac, and points to README-windows.txt for Windows specifics. Installation binaries for various platforms are listed at https://mosquitto.org/download/.

### How do I publish and subscribe with mosquitto_pub and mosquitto_sub?

Subscribe with mosquitto_sub -t 'test/topic' -v and publish with mosquitto_pub -t 'test/topic' -m 'hello world'. With the broker started as plain mosquitto, this only works from the local computer because that mode allows anonymous access locally.

### How do I install the Mosquitto broker?

The README sends readers to https://mosquitto.org/download/ for installing binaries on various platforms, and notes that a binary package usually starts the broker automatically. Building from source is done with make on most platforms and cmake on Windows and Mac.

## Sources

- [eclipse-mosquitto/mosquitto on GitHub](https://github.com/eclipse-mosquitto/mosquitto)
- [Issues](https://github.com/eclipse-mosquitto/mosquitto/issues)
- [Project website](https://mosquitto.org)
- [README](https://github.com/eclipse-mosquitto/mosquitto/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eclipse-mosquitto-mosquitto