BunkerM: A Self-Hosted Mosquitto Broker With a Dashboard, SQLite Message History and an Optional Cloud Assistant

The problem BunkerM targets: Mosquitto administration without config-file editing

Eclipse Mosquitto is a small broker, and that is the point. Access control is the part that grows. Mosquitto's Dynamic Security plugin moves clients, roles, groups and topic rules into a runtime-managed store, but the plugin still expects you to drive it through mosquitto_ctrl or the plugin's own control topics. BunkerM's answer is a web UI on top of that plugin, plus a dashboard, an MQTT Explorer view and a message store, all packaged with the broker itself. The audience is the operator who has to add a device, rotate a password or deny a topic prefix on a Tuesday afternoon and would rather click through a form than recall the exact argument order for a control command. The README frames the project as a containerized MQTT management platform and states that the broker, the dashboard, a local statistical engine, a local automation engine and a local AI engine all run inside the container. That single-container claim is the actual product decision here: you are not installing a management layer next to a broker you already run, you are replacing the broker image with one that has opinions.

What is actually inside the container: broker, dynamic security, SQLite history, agents

The README describes four engines running locally. The broker is Eclipse Mosquitto with MQTT 3.1.1 and 5 support. Access control is delegated to Mosquitto's Dynamic Security plugin, and the UI exposes clients (create, update, delete, enable, disable, assign to groups), roles with allow and deny rules per topic, and groups. Credentials are stored as a password hash, per the client management description. Message History and Replay stores every MQTT message locally in SQLite and makes it searchable and replayable, which is a different design from a broker that only keeps retained messages: the retained-message count appears separately on the dashboard, so the history store is an additional layer, not a replacement. Anomaly detection is described as statistical, naming Z-score, EWMA, spike and silence detectors. That matters because it means detection runs on local aggregations rather than on a model call, so it keeps working with no network. Automation is split into cron schedulers and condition-based watchers, which the README groups under Agents. The AI layer has two tiers: a local assistant through LM Studio, and the optional BunkerAI cloud assistant reachable from Telegram, Slack or the built-in web chat. The repository is TypeScript, which is consistent with a web frontend and an API service wrapping the broker rather than a broker written from scratch.

Getting it running: one docker run, three volumes, one environment variable

The minimal path in the README is a single command: docker run -d -p 1900:1900 -p 2000:2000 bunkeriot/bunkerm:latest. Port 1900 carries MQTT and port 2000 serves the web UI. The README states that the default MQTT credentials are username bunker and password bunker, and that the first visit to http://localhost:2000 runs a setup wizard where you create the Admin account. For anything beyond a look, the documented persistent form adds three volumes: mosquitto_data at /var/lib/mosquitto, mosquitto_conf at /etc/mosquitto, and auth_data at /data. The separation is informative. Broker state and broker configuration live in the first two, while the dynamic security store sits in /data, so a container recreated without the auth_data volume would come back with the broker config intact and the client and ACL data gone. For access from another machine, the README passes HOST_ADDRESS as an environment variable set to your IP or domain. The Compose example repeats the same three volumes and sets HOST_ADDRESS to localhost, with a commented BUNKERAI_API_KEY line for the optional cloud tier. The documented first steps are: create the Admin account, go to ACL then Clients and create a client with a username and password, point the device at localhost:1900 with those credentials, then watch the Dashboard. Nothing in the supplied material describes a configuration file for the management layer itself, so the environment variable and the volumes appear to be the whole surface.

Where the design creates friction: shared credentials, one container, and a thin upgrade story

Three things stand out as costs rather than features. First, the default broker credentials are published in the README as bunker/bunker on a port that the quick start maps to the host. That is fine for a laptop and wrong for anything reachable, and the README does not describe a mandatory credential change at first boot; the setup wizard creates the Admin account for the web UI, which is a separate credential from the MQTT client. Second, the all-in-one packaging means the broker and the management layer move together. If you want to track upstream Mosquitto releases closely, or run the broker with a configuration the UI does not model, you are working against the image rather than with it. Third, the release history in the supplied material shows v1.1.0 in February 2025, v1.2.0 in March 2025, and then v2.0.0 in March 2026, with the most recent push in May 2026. A jump from 1.2.0 to 2.0.0 across a year is a major-version boundary, and the material gives no migration notes for it. Anyone running 1.2.0 should treat the ACL and auth data under /data as the thing to back up before attempting that move, and should confirm the upgrade path from the project's own documentation rather than assuming the volumes are compatible. The README also does not state resource requirements, so sizing the container is guesswork from the README alone.

The AI features are optional and tiered, and that shapes the licence question

BunkerM splits into a Community tier and BunkerAI. The README's own comparison section is titled Community vs BunkerAI, and the cloud assistant is described as an optional subscription that adds Telegram, Slack and unlimited interactions. The local assistant through LM Studio is listed as a core feature and is described as fully private with no cloud required, so the anomaly detection, the agents and the local LLM path appear to sit in the free tier. The practical consequence is that the AI headline in the project description is partly a paid add-on, and the free part is the statistical engine plus a local model you host yourself. On licensing: the repository is Apache-2.0, which permits commercial use and modification, but a subscription to a hosted cloud service is a separate agreement that the Apache licence does not cover. Whether the BunkerAI service processes your MQTT payloads, and under what terms, is not something the supplied material answers. If message content leaving your network is a problem for your deployment, the LM Studio path is the one the README positions as local, and the cloud path is the one to read the service terms for before enabling BUNKERAI_API_KEY.

Alternatives and the real difference in approach

The closest comparison is running Eclipse Mosquitto directly with the Dynamic Security plugin and driving it through mosquitto_ctrl. That gives you upstream releases, a configuration you write yourself, and no extra process in the container. What you give up is the dashboard, the SQLite message history with replay, the anomaly detectors and the browser-based topic tree. If your ACL changes are rare and scripted, the upstream path is less machinery for the same access-control outcome. A second comparison is a hosted MQTT platform such as HiveMQ Cloud or EMQX Cloud, where the broker and its access control are someone else's operational problem and you get a console without running a container. The difference is where the data sits: BunkerM is self-hosted by design, and its message history lives in a SQLite file inside your own volume. If your constraint is that payloads cannot leave your infrastructure, the hosted consoles are ruled out before feature comparison even starts. BunkerM's own bridge configuration for AWS IoT Core and Azure IoT Hub is worth noting in this context: the README lists bridge setup as a feature, which suggests the intended pattern is a local BunkerM broker forwarding to a cloud IoT platform, not replacing it.

Maintenance cost and what to verify before adopting

The maintenance burden is mostly the container plus three volumes. Because the management layer and the broker share an image, a BunkerM upgrade is also a Mosquitto upgrade, and the v1.2.0 to v2.0.0 gap is the moment to test that on a copy of the auth_data volume rather than in place. Watch the volume layout: mosquitto_conf at /etc/mosquitto and auth_data at /data hold different things, and losing the second one loses your clients and ACL rules while leaving the broker looking healthy. The MQTT Explorer and the message history both read from the same broker, so neither adds a second source of truth about your topic tree. Before committing, verify three specific things against the project's documentation: whether the Dynamic Security plugin is the only supported authentication mode or whether password-file auth is also configurable, what the upgrade procedure is from 1.2.0 to 2.0.0 and whether the on-disk ACL format changed, and which of the features you need sit behind BunkerAI. The README answers none of those three questions.

Editorial conclusion

Adopt BunkerM if you already run Mosquitto and want client, role and topic ACL changes done through a UI instead of a config file, and if a single container for broker plus dashboard fits your deployment. Skip it if you need a broker image that stays close to upstream Mosquitto, or if you cannot accept a default credential pair of bunker/bunker on a broker port. Before rolling it out, verify three things: that the Dynamic Security plugin is what you want as the source of truth for authentication, that the /data and /etc/mosquitto volumes are mounted so ACL changes and broker config survive a container restart, and whether the features you actually need sit in the Community tier or behind the BunkerAI subscription.

Official sources

1. bunkeriot/BunkerM on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases