The readiness target is 0.4.0 and the workspace is already at 0.4.11

The status banner targets a version the repository passed in July

The development status block near the top of the page says RobustMQ is in early development and not yet production-ready, that the MQTT core is stable and continuing to mature, that Kafka, NATS and AMQP are under active development, and that production readiness is targeted for 0.4.0. The workspace manifest disagrees with the target. `[workspace.package]` in `Cargo.toml` carries `version = "0.4.11"`, and the newest release is v0.4.11, published on 2026-07-31, after v0.4.10 on 2026-07-30 and v0.4.9 on 2026-07-27. Three patch releases landed inside five days, so the line is being cut quickly. So the readiness goal has been overtaken by eleven patch releases and the banner has not moved, which makes it a statement about the project rather than a schedule. The block also mixes its own register, calling the MQTT core stable inside a paragraph that opens by calling the whole thing early. The branch itself was last pushed on 2026-09-27, two months after that tag, so there is source on main that no published artefact corresponds to.

The roadmap calls AMQP planned, the status table calls it demo validated

The roadmap is a four phase block, and the phases carry labels. Phase 1 is MQTT, marked current, with the goal of the MQTT core being production-ready and refined. Phase 2 is NATS plus the mq9 agent mailbox, marked in progress. Phase 3 is Kafka, also marked in progress, with the note that it completes the IoT to streaming data path. Phase 4 is AMQP, marked planned, for the traditional enterprise messaging migration path. The feature status table underneath disagrees on that last one. It lists the AMQP protocol as demo validated and in development, the same wording it uses for NATS and for the mq9 mailbox. A protocol cannot be both planned and already validated against a demo, and AMQP is the one the table has quietly moved ahead of the roadmap.

The npm manifest is at 1.0.0 while the Cargo workspace is at 0.4.11

There are two manifests at the root and they do not track each other. The Rust workspace declares 0.4.11. The npm manifest declares:

{
  "name": "robustmq",
  "version": "1.0.0",
  "private": true,
  "description": "RobustMQ",
  "devDependencies": {
    "vitepress": "^2.0.0-alpha.4",
    "vitepress-i18n": "^1.3.0"
  }
}

So the higher version number belongs to the documentation toolchain, not to the broker. The npm package is marked private, carries the Apache 2.0 licence and the RobustMQ Team as author, and exists for three scripts: `vitepress dev docs`, `vitepress build docs` and `vitepress preview docs`. The i18n plugin is there because the documentation is translated, which matches the other language entry point on the page. The practical consequence is that a tool scanning npm versions for this project would report 1.0.0 for a repository whose broker is four minor versions behind that number.

Thirty-nine workspace members, seventeen of them under common

The workspace members list is the clearest picture of the codebase's shape, and it has thirty-nine entries. Five of them are the protocol implementations, one per advertised protocol: `mqtt-broker`, `mq9-core`, `amqp-broker`, `kafka-broker` and `nats-broker`. Seventeen are under `src/common/`, from `common/base` and `common/config` through `common/rocksdb-engine`, `common/metrics`, `common/rate-limit`, `common/security`, `common/search-engine`, `common/third-driver` and `common/llm-engine`. The other seventeen cover the three named architectural components, `meta-service` for metadata and consensus, `broker-server` and `broker-core`, the plumbing, and the tooling: `admin-server`, `grpc-clients`, `connector`, `storage-engine`, `storage-adapter`, `rule-engine`, `schema-register`, `delay-message`, `protocol`, `cli-command`, `cli-bench`, `cmd`, `robustmq-macro` and `tests`. Two entries are unusual: `tests` is a workspace member in its own right rather than a directory outside the build, and `common/llm-engine` is a language model component sitting inside a message broker. The workspace declares `resolver = "2"` and `edition = "2021"`, and the licence is set once at the workspace level rather than per crate.

One binary with zero dependencies, over a workspace that pins openssl-sys

The headline is one binary, one broker, no external dependencies, deployable from edge devices to cloud clusters. The architecture section backs that with three components that are said to have fixed boundaries: a Meta Service holding metadata and Raft based consensus, a Broker doing protocol parsing and routing, and a Storage Engine holding unified data storage with pluggable backends. The claim to check is the dependency one. The storage modes are listed as memory, RocksDB and file, per topic, with automatic cold data tiering to S3. The dependency block in `Cargo.toml` carries a comment about forcing every transitive consumer of `openssl-sys` into one version, which is what you do when native TLS enters the build. So zero dependencies is a statement about what you deploy, not about what gets compiled: no database process and no ZooKeeper, but a TLS stack and a local RocksDB in the same binary. The feature list keeps to the same deployment framing elsewhere, promising offline buffering with automatic sync for edge gateways, built in Raft consensus, and a shared subscription that breaks the limit where concurrency equals partition count.

mq9 is documented at length and lives in another repository

The fifth protocol gets the largest section on the page and is the one with the most moving parts. It is positioned against general purpose registries such as etcd and Consul paired with general purpose queues such as Kafka and NATS. Its two stated problems are how agents find each other, answered with a registry exposing `AGENT.REGISTER` and `AGENT.DISCOVER` with full text and semantic vector search, and how they communicate reliably, answered with a persistent mailbox per agent where messages wait until the recipient is online, with three priority tiers of critical, urgent and normal and FETCH plus ACK pull consumption. The data model is an AgentCard, discovery is capability based, and there is N to N topology with long task state retention. Integration is offered through an `mq9.a2a` facade wrapping the official a2a-sdk, native NATS clients, SDKs for Python, Go, TypeScript, Java and Rust, a `langchain-mq9` toolkit, and an MCP server over JSON-RPC 2.0, with MCP and ANP named for forward compatibility. The documentation and the code are both pointed at a separate repository, `robustmq/mq9`, rather than at this tree. Note where the status banner does and does not reach: it names Kafka, NATS and AMQP as under active development and leaves mq9 out, while the roadmap files mq9 alongside NATS in phase two and the feature table marks the agent mailbox as demo validated and in development.

The install instructions the page promises stop before the commands

The quick start section is headed One-Line Install and then the page stops. Everything after the architecture section, which covers the install path, the documentation links, the contributing notes and the community pointers, is not visible here, so the actual command for getting the binary is not something this page supplies. What is visible instead is the set of deployment shapes sitting in the tree, which do suggest the intended paths: an `example/mqtt-cluster/` directory for a bare cluster, `example/test-network-docker/` for a Docker network, `example/test-network-k8s/` for Kubernetes, and a standalone `ws-mqtt.html` for a WebSocket client. The rest of the root is a Rust project with its full supporting cast: `bin/`, `benches/`, `chaos-test/`, `config/`, `docker/`, `grafana/`, `scripts/`, `src/` and `tests/`, alongside a lowercase `makefile`, `flake.nix`, `shell.nix`, a `rust-toolchain.toml`, a `deny.toml` for dependency policy, a `cliff.toml` for changelog generation, `_typos.toml`, and an `operator/` directory. Three of those are worth a second look: the build file is lowercase where Rust tooling looks for a capitalised one, `chaos-test/` says failure testing is part of the plan rather than an afterthought, and an `operator/` directory suggests a Kubernetes controller is intended alongside the test network rather than instead of it.

Editorial conclusion

RobustMQ is worth evaluating if you are deliberately running several message brokers and want them replaced by one, since the shared storage layer is the actual product claim and the multi protocol support is the reason to believe it. Do not evaluate it as a drop in Kafka replacement on the strength of the page, because the status table marks the Kafka protocol as in development. Treat the version numbers as untrustworthy: the banner, the tags and the two manifests disagree, so find out what you actually installed. And read the storage section carefully, since a file to RocksDB to S3 tiering ladder behind a claim of zero dependencies is where the operational cost will land.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes