MQTT Web Interface

A Python-based web UI for MQTT debugging, visualization, and automation rules — honestly reviewed.

TL;DR

• What it is: Open-source (MIT) web application that sits on top of your MQTT broker, giving you real-time message visualization, an automation rules engine, alerting to Telegram/Slack, and per-topic analytics — all from a browser [1][README].
• Who it’s for: Home lab builders, IoT hobbyists, and small teams running self-hosted MQTT infrastructure who want a dashboard and light automation without wiring up a full platform like Thingsboard or Node-RED.
• Cost savings: Commercial IoT monitoring platforms (AWS IoT Core, HiveMQ Cloud, Datadog IoT) run $20–$200+/mo depending on device count and message volume [2]. MQTTUI runs on a $5–10/mo VPS alongside your broker — or on the same Raspberry Pi already running Mosquitto.
• Key strength: The fastest path from “I have an MQTT broker” to “I can see what’s happening and set up IF/THEN rules” — Docker Compose up, browser open, done [README].
• Key weakness: Small project — 196 GitHub stars, 14 forks, one primary author. No community reviews beyond the original Reddit launch post. If this project stalls, you own the maintenance [1].

---

What is MQTT Web Interface

MQTTUI (the actual name of the project, found at github.com/terdia/mqttui) is a Python web application — Flask-based, using Alpine.js and htmx on the frontend — that connects to one or more MQTT brokers and gives you a real-time dashboard over them [README].

The v1 release, announced on r/selfhosted in 2024, was straightforwardly described by the author: “while there are feature-rich alternatives out there, MQTT Web Interface aims to be your go-to tool for rapid MQTT debugging and monitoring” [1]. One Docker command, port 5000, done. That original simplicity pitch was honest — it was a visualization and publish tool, nothing more.

v2.0 and v2.1 added substantially more: an automation rules engine, Telegram/Slack alerting, a REST API with OpenAPI docs, user authentication, per-topic analytics with Prometheus export, a plugin system, and multi-broker support [README]. The GitHub description now calls it “Intelligent MQTT Web Interface” — which is marketing creep, but the features are real.

The tech stack: Python backend (wsgi.py), SQLite for message persistence, Socket.IO for real-time streaming, Vis.js for the topic graph, 218+ automated tests via pytest [README]. It handles 1,000+ messages/second with server-side batching. The multi-arch Docker image covers AMD64, ARM64, and ARMv7 — meaning it runs on a Raspberry Pi without recompiling [README].

What it is NOT: an MQTT broker (you still need Mosquitto, EMQX, HiveMQ, or similar), an IoT platform with device management, or a high-availability production monitoring stack. It’s a dashboard + light automation layer sitting in front of your existing broker.

---

Why people choose it

The honest answer is that the third-party review landscape for MQTTUI is thin. It has 196 stars, one Reddit launch thread, and no published reviews on G2, Trustpilot, or tech media as of this writing. What exists is the author’s own launch post [1] and context from the broader MQTT self-hosting community [3].

What the r/selfhosted thread [1] captures, though, is the actual gap MQTTUI fills. The MQTT ecosystem has exactly two camps: heavyweight IoT platforms (Thingsboard, Node-RED, Grafana + InfluxDB stacks) and bare-bones desktop clients (MQTT Explorer, MQTT.fx). There is almost nothing in the middle that gives you a persistent web UI with basic automation, deployable in a single Docker Compose command, that doesn’t also require you to configure flows or write code.

Home Assistant’s MQTT integration [3] is the other comparison point — if you’re already running Home Assistant, you get MQTT entities and automations through HA. But HA is an entire platform. If your goal is just to watch MQTT traffic and trigger a webhook when a sensor exceeds a threshold, HA is massive overkill. MQTTUI’s rules engine handles that specific case with a few clicks.

The IoT monitoring comparison matters more for commercial context. Services like Adafruit IO, Thingspeak, and Cayenne offer cloud-based MQTT visualization and dashboards, but they put your data through their servers and impose message limits on free tiers [5]. MQTTUI keeps messages in your own SQLite database, on your own hardware, with no per-message cost.

---

Features

Based on the README and GitHub source:

Core monitoring:

• Real-time MQTT message streaming (Socket.IO, 1000+ msg/sec) [README]
• Interactive topic hierarchy network graph (Vis.js) — see how your topic tree is structured visually
• Publish messages directly from the browser
• SQLite message persistence with advanced search: regex, JSON path, time range [README]
• MQTT v3.1.1 and v5 protocol support
• Multi-broker: connect to multiple brokers simultaneously, filter messages by broker (v2.1) [README]
• Filter presets — save and reload search combinations
• Topic favorites/bookmarks, retained message indicator

Automation rules engine (v2.0+):

• IF/THEN rules: when a topic matches a pattern and payload meets a condition, fire an action [README]
• 11 condition operators: eq, gt, contains, regex, exists, and more
• Compound logic: combine conditions with all/any (AND/OR)
• JSON Path conditions: match nested payloads like sensors.outdoor.temp > 30 [README]
• Actions: publish to topic, HTTP webhook, log alert
• Cron-based time rules via APScheduler (e.g., publish heartbeat every 5 min)
• Dry-run testing: validate rules against sample payloads before activating
• Hot-reload: changes take effect without restart
• Loop detection: __source marker + per-rule rate limiting + global circuit breaker (this matters — a bad rule publishing to the trigger topic could loop forever without this) [README]

Alerting:

• Telegram: bot token + chat ID, done (v2.1 makes this first-class, no raw webhook needed) [README]
• Slack: incoming webhook URL
• HTTP webhooks: customizable templates ({{topic}}, {{payload}}, {{timestamp}})
• Exponential backoff retry (1s / 5s / 25s) on server errors
• SSRF protection — blocks private/reserved IP ranges
• Alert deduplication with configurable cooldown (5 min default)
• Persistent alert history with delivery status

Analytics and observability:

• Per-topic message rate counters and numeric payload histograms
• Prometheus-compatible /metrics endpoint — plug into your existing Grafana stack [README]
• Structured JSON logging (structlog) for production
• REST API at /api/v1/ with OpenAPI docs at /api/v1/docs

Plugin system:

• MQTTUIPlugin base class with on_message, on_connect, on_rule_trigger hooks
• Subprocess isolation — plugins cannot access app internals
• pip-installable plugins via Python entry points
• Bundled examples: JSON Formatter, Topic Logger

---

Pricing: SaaS vs self-hosted math

MQTTUI has no SaaS tier — it’s purely self-hosted MIT software. The cost question is: compared to what?

Cloud IoT monitoring alternatives:

• HiveMQ Cloud free tier: 100 connected devices, limited message retention — adequate for dev, insufficient for anything real [2]. Paid tiers are enterprise-priced.
• AWS IoT Core: $0.08 per million messages, plus device shadow storage, plus rule actions charges. A sensor sending a reading every 30 seconds is ~3M messages/month — around $0.24/mo on messages alone, but quickly accumulates with rules, indexing, and dashboards.
• Adafruit IO: free tier caps out fast (30 data points/minute); Plus is $10/mo for 60 feeds [5].
• Thingsboard Cloud: free tier is limited; Professional Edition starts at $10/mo (self-hosted) to $20+/mo (cloud).

Self-hosting MQTTUI:

• Software: $0 (MIT)
• MQTT broker (Mosquitto): $0 (also free)
• VPS to run both: $5–10/mo — or $0 if you’re already running a home server or Raspberry Pi
• Storage: SQLite, embedded — no separate database bill

For a home lab or small business with 10–50 sensors sending data every few minutes, MQTTUI + Mosquitto on a $6 Hetzner VPS is the full stack. Total: $6/mo with no per-message pricing, no device count limits, no data leaving your network.

The case for a paid IoT platform only makes sense when you need managed uptime, mobile apps, or multi-site device management that MQTTUI doesn’t attempt.

---

Deployment reality check

The Docker Compose path is the recommended install and it’s genuinely simple [README]:

git clone https://github.com/terdia/mqttui.git
cd mqttui
docker compose up -d

This starts Mosquitto on port 1883 and MQTTUI on port 8088. The bundled docker-compose.yml wires them together. If you already have a broker running, you point MQTTUI at it via environment variables.

What you need:

• A host with Docker and Docker Compose (Linux VPS, Raspberry Pi, home server)
• Port 8088 accessible from your browser (or behind a reverse proxy for HTTPS)
• MQTTUI_ADMIN_USER, MQTTUI_ADMIN_PASSWORD, SECRET_KEY, and MQTT_BROKER environment variables [README]

What can go sideways:

The multi-arch Docker image covers ARM64 and ARMv7, so Raspberry Pi deployment works — but the XDA Developers article [4] makes a relevant general point about running persistent services in containers on weak hardware: if you’re on a shared Proxmox LXC node running Docker-in-LXC, nested container stability becomes a consideration. MQTTUI itself is lightweight (Python + SQLite), but factor in your hosting environment.

SQLite is the persistence backend. Fine for development and home use, but SQLite under concurrent heavy write load (many topics, high message rates) will eventually show contention. The README mentions server-side batching at 1000+ msg/sec, which mitigates this, but long-term high-volume production use would benefit from moving message storage to PostgreSQL — which is not a currently documented option.

There’s no upgrade migration documentation visible in the README or CHANGELOG. With SQLite schemas evolving across v1 → v2 → v2.1, upgrading a live instance with message history may require manual database migration. Worth testing in dev before upgrading production.

Realistic setup time: 15–30 minutes for a technical user on a fresh VPS. Reverse proxy and HTTPS add another 30 minutes.

---

Pros and Cons

Pros

• MIT license, genuinely open. Fork it, embed it, do what you want [README].
• Single Docker Compose command to a working stack. Broker included. This is the smoothest quickstart in the category [README][1].
• Automation rules engine without a full platform. IF/THEN rules with Telegram/Slack alerts, JSON path conditions, and cron schedules — without running Node-RED or Home Assistant [README].
• Prometheus endpoint included. If you have Grafana, you can plug MQTTUI metrics straight in without extra config [README].
• Loop detection built into rules engine. A subtle but important safety feature — bad automation rules that trigger themselves are caught before they flood your broker [README].
• 218+ automated tests. For a small project, this is unusually thorough coverage — reduces the “it works on the author’s machine” risk [README].
• Multi-arch Docker. AMD64, ARM64, ARMv7 — runs on a Pi without building from source [README].
• OpenAPI docs included. The REST API at /api/v1/ is documented — you can script against it programmatically [README].

Cons

• Tiny community. 196 stars, 14 forks, one primary maintainer [GitHub]. No forum, no Discord, no community support. If you hit a bug, you’re either opening a GitHub issue or reading the source.
• No migration docs. Schema changes between major versions are a real concern with SQLite-backed storage. Data preservation across upgrades is on you.
• SQLite ceiling. Not a production-grade message store for high-frequency sensor networks. Fine for home use, worth monitoring for larger deployments.
• No external auth. Username/password only. No LDAP, no SSO, no OAuth. Single-user admin model [README].
• Python runtime. Nothing wrong with Python, but it’s heavier than Go-based alternatives for resource-constrained hardware.
• The “Intelligent” branding is noise. The README now leads with “Intelligent MQTT Web Interface” — the features are real but the framing is hype. It’s a solid monitoring and light-automation tool, not an AI product.
• No cloud or hosted option. Self-host or nothing. That’s fine for the audience here, but worth stating explicitly.

---

Who should use this / who shouldn’t

Use MQTTUI if:

• You’re running Mosquitto or another broker already and want a browser-based dashboard without setting up a full IoT platform.
• You want to trigger Telegram or Slack alerts when sensor values cross thresholds, without writing code.
• You’re on a Raspberry Pi or low-cost VPS and need something lightweight.
• You want MQTT visibility for a home automation project that doesn’t use Home Assistant.
• You’re debugging MQTT message flows and need something faster than mosquitto_sub piped to a terminal.

Skip it (use Node-RED instead) if:

• You need complex multi-step automation flows with branching logic, function nodes, and 400+ pre-built integrations.
• Your team isn’t comfortable maintaining a small Python app on a server.
• You want an active forum and community support.

Skip it (use Home Assistant) if:

• You’re already in the HA ecosystem — it includes MQTT integration, automations, and dashboards that are deeper and better-maintained than anything MQTTUI offers.

Skip it (use Thingsboard) if:

• You need multi-tenant device management, asset hierarchies, and a production-grade time-series database behind your IoT data.

Skip it (use MQTT Explorer) if:

• You just want to inspect messages on a laptop occasionally. MQTT Explorer is a desktop client that does this with zero server setup.

---

Alternatives worth considering

• Node-RED — open source, MIT, flow-based automation with 4,000+ nodes. Much more powerful for complex automation; steeper setup. The obvious upgrade path if MQTTUI’s rules engine becomes limiting.
• MQTT Explorer — desktop client (no server needed), excellent for debugging. Not persistent, no alerts, no automation. Different use case.
• Thingsboard — full IoT platform, open source community edition, self-hostable. Overkill for home use; appropriate for fleet management.
• Grafana + InfluxDB + Telegraf — the standard self-hosted observability stack. Better dashboards, more scalable, significantly more setup complexity.
• Home Assistant — if you’re doing home automation specifically, HA’s MQTT integration plus automations replaces everything MQTTUI does, with better long-term support.
• EMQX — MQTT broker with a built-in dashboard and rule engine. If you’re not locked into Mosquitto, EMQX bundles much of what MQTTUI adds on top.
• HiveMQ Cloud — managed MQTT with a browser dashboard [2]. Commercial, data leaves your network, free tier is limited.

---

Bottom line

MQTTUI solves a specific problem cleanly: you have an MQTT broker, you want to see what’s happening in a browser, and you want to set up a few automation rules without running a full platform. The Docker Compose quickstart works, the rules engine is genuinely useful, and the Telegram/Slack alerting covers the most common home lab notification use case. For that narrow job, it’s the fastest path from zero to a working MQTT dashboard.

The risk is the project size. One maintainer, 196 stars, no commercial backing — that’s a legitimate long-term concern if you’re building anything critical on top of it. Evaluate that honestly against your use case. For a home lab or internal IoT monitoring project, the downside of a stalled project is manageable — you have the MIT source code and a straightforward Python codebase you can fork. For customer-facing or production-critical monitoring, you’d want something with a larger community behind it.

If you want this deployed and configured without spending an afternoon on it, that’s the kind of one-time setup upready.dev handles for clients.

---

Sources

1. terdia, r/selfhosted — “Introducing MQTT Web Interface: A Lightweight, Open-Source Tool for Real-Time MQTT Visualization”. https://www.reddit.com/r/selfhosted/comments/1ew0m8y/introducing_mqtt_web_interface_a_lightweight/
2. HiveMQ — “The Best Free Public MQTT Broker & MQTT Client by HiveMQ”. https://www.hivemq.com/mqtt/public-mqtt-broker/
3. Home Assistant Community — “Self hosted MQTT - what are the actual options?!”. https://community.home-assistant.io/t/self-hosted-mqtt-what-are-the-actual-options/444869
4. Ayush Pande, XDA Developers — “4 self-hosted services I’d rather deploy as VMs instead of containers” (Aug 28, 2025). https://www.xda-developers.com/services-id-rather-deploy-as-vms-instead-of-containers/
5. Hackaday — “Review: IoT Data Logging Services With MQTT” (Oct 31, 2017). https://hackaday.com/2017/10/31/review-iot-data-logging-services-with-mqtt/

Primary sources:

• GitHub repository and README: https://github.com/terdia/mqttui (196 stars, MIT license)