MQTT Explorer's compose file ships a default password and its image is a test harness

Four badge slots, one of them duplicated, and none pointing at the documented workflow

The file opens with a row of five badges, all of them empty links carrying no text. Two of the five are byte-identical, pointing at the same releases page on one continuous integration service. The other three point at that service's project page, at a second service's build for the default branch, and at a code quality service. So four badges for four targets, one of them repeated. Now set that against what the file actually tells you to do. The quickest development route it describes is a hosted development environment: click a button, wait while the environment is prepared, and the readme says that wait includes a Node runtime and an MQTT broker. A dev container directory is in the tree with its own readme. So the documented development path is a browser-based workspace, while the badges advertise two other services, one of which is a continuous integration system whose free tier for open source projects ended years ago. The tree also holds an AppVeyor configuration, so that badge at least points at something real, and a dependency-update bot configuration, which is a fourth external system that nothing in the badges or the prose mentions.

The manifest is one beta behind the newest tag and the three tags use three conventions

The version in the manifest is a beta of a zero major line. The three published tags are that same beta line, and none of them is named the way the others are. One carries a v prefix and a dotted beta suffix. The next has no prefix and an undotted beta number. The third, from April 2020, has a placeholder version in front of the real one, separated by a hyphen, which is a publishing convention rather than a version. Three tags, three naming schemes, and a fourth spelling in the manifest that matches none of them, because the manifest is one release behind the newest tag. The cadence is stranger than the naming. One tag in April 2020, then nothing for four years, then two tags four days apart in May 2024, then nothing for seventeen months. The branch itself was last pushed on 8 May 2026, so there is five months of work sitting on top of a beta that was published in May 2024. One more detail in the same manifest: the field that marks a package as not for publication is set to a quoted string rather than a boolean, which is a type error in a file whose readers expect booleans there.

The one-line container deployment sets the admin password to a guessable word

There are two container routes and one of them is much weaker than the other. The prose route spells out a run command with a placeholder that literally says to substitute a secure password:

docker run -d \
  -p 3000:3000 \
  -e MQTT_EXPLORER_USERNAME=admin \
  -e MQTT_EXPLORER_PASSWORD=your_secure_password \
  -v mqtt-explorer-data:/app/data \
  ghcr.io/thomasnordquist/mqtt-explorer:latest

The compose route, which is the one you reach for when you want a single command, sets the username to admin and the password to the word changeme, on a port published to the host, with a restart policy of always. The compose file's own comment warns about the line below it, the one that disables authentication outright for use behind an authenticating proxy. It does not warn about the password above it. So the fastest documented deployment of a tool whose whole job is to show you every message on a broker ships with a guessable admin credential, one variable away from no credential at all, and the warning in the file is attached to the safer of the two options. The health check is a small inline script that fetches the root path and exits according to the status code, which is a reasonable way to avoid marking a container healthy before the server is listening.

The visible container file is a test harness with an anonymously accessible broker

The repository contains two Dockerfiles, one named plainly and one named for browser mode, and the documentation never says which one produced the published image. The one whose contents are visible here is not an application image. It installs a text editor, a video encoder, a virtual framebuffer, a terminal multiplexer, a remote desktop server, a message broker, and a long list of desktop toolkit libraries. It then writes a broker configuration that opens a listener and explicitly allows anonymous connections, with a comment saying this is required for the tests. It installs a browser automation tool at an exact version along with its browser. Its declared command is an interactive shell rather than the application, and the port it declares is the remote desktop one rather than the application's. That combination is entirely coherent for running the project's own test suite, which the readme says needs a broker, a virtual framebuffer, a terminal multiplexer and a video encoder. It is not coherent as a published application image, and since the run command above names the image without passing a command, the default command is what would start. One mitigating detail: the documented run command publishes only the application's port, so the broker inside the container is not reachable from the host unless you add a mapping for it.

Four differently named test commands are byte-identical and three are undocumented

The manifest defines a test command for the Electron application, one for the browser, one for the mobile user interface, and one for the user interface in general. All four are the same two commands: compile the project, then run one spec file under a test framework with source map support. So the test matrix implies four environments and the manifest implements one, four times over. Three of the four names appear nowhere in the readme. Only the general one is documented, and it is documented twice, once as a deterministic browser suite and once as the thing you run for the offline language model tests, which is the same command as the frontend unit tests described under a different heading three sections earlier. The language model section's live variant differs from the offline one by three exported environment variables and a note that the model provider can be one of two, so the design is that the model tests live inside the frontend suite and skip themselves unless those variables are set. That is a reasonable arrangement; presenting one command under two headings with two descriptions is what makes it read as an error.

Running all the tests requires a video encoder and a virtual framebuffer

There are two aggregate commands and they are not equivalent. One runs the frontend suite and the backend suite. The other runs those two and then the demo video generation. Since the readme lists what the video generation needs, the aggregate command needs four system packages installed before it can pass: a broker, a virtual framebuffer, a terminal multiplexer and a video encoder. So the command named for running all the tests is the one you cannot run on a bare checkout, and the shorter one is the practical default. The same dependencies are the reason there are shell scripts wrapping the UI suite, one for the full recording setup with cleanup and one for a remote desktop variant, plus a third for the mobile recording. There is also a documentation script for a hosted development environment that wraps the same setup. Four wrappers around one workflow is a sign of how much environment preparation the video tests need. One more pattern worth noting: most of the server and test scripts begin by invoking the TypeScript compiler, so each of those commands recompiles the project before it does anything else.

The mobile story is told three times and its test command is the desktop one

Mobile support gets more documentation than anything else in the file. There is a section on generating a mobile demo video, a section on mobile compatibility, two documents at the repository root, two test scripts, and five screenshots at the root whose names begin with mobile. The target device is named twice, a specific handset model with a viewport size, and the design rule is a minimum tap target size given in pixels. The scripts are the interesting part. There is one command for generating a mobile demo video, which is a distinct file from the desktop one. And there is a command for mobile interface tests, which is one of the four aliases of the desktop suite, running the identical spec file. So the mobile viewport strategy and the tap target rule are documented in detail, while the test that would check them is the same test as the desktop one. The screenshots make the history visible too: several are named for a state before connecting, states after connecting, and a sequence of expanding panels, which reads as a record of one mobile debugging session kept at the repository root rather than filed as documentation.

Sixteen documents and nine screenshots sit at the repository root

The top level of the tree is where this project's habits show. Sixteen markdown files sit beside the source, and they are not all documentation a user needs. Alongside the deployment, browser mode, styling and security documents there is an implementation summary, a document about debugging the language model tests, a document of debugging examples, and a document about testing with an API key. There is a changelog file and a release configuration, and the release tags are the other record. Environment variables are documented twice, once as an example file at the root and once as a document. There is a package manifest and, beside it, a second file whose name differs only by its extension. Two small script files with timing and runtime-check names sit at the root next to a test output directory, which is a build artefact location rather than a source one. Nine images are at the root too, one of them an editable vector icon source, and five of them mobile debugging screenshots as described above. The linting setup is also of two generations at once, a configuration file and a separate ignore file for the linter, plus separate ignore and configuration files for the formatter and a spell-check dictionary.

Editorial conclusion

MQTT Explorer suits someone who wants to see what a broker is actually carrying without reading raw packets, and who will run it on a trusted network or behind an authenticating proxy. Check six things first. The compose file sets a literal guessable password for the admin user on a published port, and there is a variable that removes authentication entirely, so the deployment is only safe behind a proxy. The visible container file is a test harness: it installs a broker configured for anonymous access, a virtual framebuffer, a terminal multiplexer, a video encoder and a remote desktop server, and its command is an interactive shell. Four test command names resolve to one suite, and the mobile one is the desktop one. The aggregate test command requires four system packages a bare checkout will not have. The manifest is one beta behind the newest tag and the three tag names follow three conventions. And the branch was last pushed on 8 May 2026 with no release since May 2024, so plan around that.

Frequently asked questions

Official sources

1. License: CC-BY-4.0
2. Project website
3. README
4. Releases
5. thomasnordquist/MQTT-Explorer on GitHub