BunkerM: The "Fat Sidecar" That Hardens the IoT Edge

How a containerized security layer transformed Eclipse Mosquitto from a silent broker into a managed, anomaly-detecting gateway.

8 min read • View on GitHub • More from bunkeriot

A massive vaulted bunker door with dozens of small glowing data cables plugged directly into its surface, representing a secure IoT gateway. — BunkerM wraps the industry-standard Mosquitto broker in a protective, managed API layer.

This release turns BunkerM into a complete Mosquitto management platform, giving you full control over your broker with ease. 🎉

— Mehdi Idrissi, Author / Creator (Source)

Key Takeaways

BunkerM wraps the Eclipse Mosquitto broker in a sidecar API to enable security configuration changes without restarting the service.
The platform uses exponentially weighted moving averages to detect and flag statistical anomalies in sensor telemetry.
A "fat container" architecture bundles the entire management stack into a single appliance for simpler deployment on resource-constrained edge hardware.
Automated bridging tools simplify the process of syncing local industrial data to major cloud providers like AWS and Azure.

The Cost of a Restart

In industrial IoT, data never sleeps. A factory floor sensor streams telemetry continuously. Traditional MQTT management makes securing that stream a brittle process. To change a user's permissions in a standard Eclipse Mosquitto setup, you edit a text file and restart the service. That restart drops every active IoT connection.

This is the inherent friction of the edge. Mosquitto is powerful and ubiquitous, but it is entirely static by default. BunkerM emerged to solve this exact operational pain. It turns Mosquitto into a living, API-driven gateway that never needs a reboot.

It acts as a specialized security appliance. By wrapping the broker in a modern control plane, BunkerM delivers the "Docker Desktop" moment for the industrial edge.

Orchestrating the "Silent" Broker

The magic relies on Mosquitto's obscure Dynamic Security (DynSec) plugin. DynSec allows configuration changes on the fly, but it requires complex JSON payloads or cumbersome CLI commands. BunkerM abstracts this entirely.

The architecture uses a fleet of Python FastAPI sidecars. These micro-APIs wrap the mosquitto_ctrl utility, exposing a RESTful interface for identity and access management. When an administrator clicks a button in the Vue-based frontend, Nginx routes the request to the appropriate sidecar. The sidecar translates the intent into a dynamic security command, and Mosquitto updates instantly.

A flow diagram showing the "Fat Sidecar" request lifecycle. It starts with a "Frontend (Vue)" node sending an API request. The request passes through an "API Gateway (Nginx)" node

A hand adjusting a dial on a complex machine while the machine is running, illustrating zero-downtime reconfiguration. — BunkerM allows administrators to alter access control lists while the broker continues processing telemetry.

Security Beyond the ACL

BunkerM moves beyond simple access control by introducing an active monitoring layer. The system includes a dedicated Smart Anomaly service. This is not generative AI hype. It is applied statistical analysis designed for high-frequency sensor data.

The engine calculates Exponentially Weighted Moving Averages (EWMA) and standard deviations for incoming MQTT topics. If a sensor suddenly transmits values three standard deviations outside its historical baseline, the system flags it. This allows administrators to detect hardware failures or malicious data injections before they corrupt downstream databases.

A single cracked gear tooth on an otherwise pristine clockwork mechanism, contained by a firewall line. — The anomaly engine isolates statistical deviations before they impact the broader system.

The "Fat Container" Philosophy

Modern cloud architecture often demands one process per container. BunkerM explicitly rejects this for the edge. It uses a "Fat Container" approach, bundling Nginx, Mosquitto, Python APIs, and Node.js services into a single deployment orchestrated by Supervisord.

This appliance model trades microservice purity for operational simplicity. For an engineer deploying to a constrained factory server, managing one unified Docker image is significantly safer than orchestrating a complex Kubernetes manifest.

Feature	BunkerM	Traditional Mosquitto	EMQX
Deployment	Single Container Appliance	Multi-service (Broker + UI + DB)	Distributed Cluster
Security Updates	Dynamic (No Restart)	Static (Requires Restart)	Dynamic (Native Dashboard)
Intelligence	Statistical Anomaly (EWMA)	None (Requires External Tools)	Complex Rule Engine
Target Use Case	Edge / Industry 4.0	General Purpose Routing	Massive Scale SaaS

Bridging the Edge to the Cloud

Data collected at the edge rarely stays at the edge. Industrial deployments inevitably need to sync local topics to centralized cloud providers like AWS IoT Core or Azure IoT Hub. Historically, configuring these bridges meant navigating a maze of certificate formats and manual configuration files.

BunkerM automates this bridging process. Its backend services act as a template engine, translating high-level UI inputs into the precise syntax Mosquitto requires for cloud synchronization. It handles the SAS tokens and SSL certificates, turning a fragile manual chore into a repeatable, managed workflow.

A massive stone bridge connecting a small fortified island to a glowing nebula in the sky, representing edge-to-cloud bridging. — BunkerM automates the complex certificate management required to bridge local telemetry to AWS and Azure.

A live-moving line graph visualizing the Statistical Sentry. The diagram shows a "Sensor Stream" node feeding data points into a "Metric Engine" node. A baseline line (EWMA) follows the data smoothly. When a data point sharply diverges from the baseline crossing a specific "Threshold" (Z-score > 3)

Sources: BunkerM Repository; Author Announcement.