Apache RocketMQ Externals: the community directory that surrounds the broker

A directory of projects rather than a library you depend on

The first thing to understand about rocketmq-externals is that it is not a component. The repository description calls it a mirror of Apache RocketMQ while the README describes it as the community projects home, and both descriptions are trying to explain the same odd thing: this is where satellite projects live until they are big enough to deserve their own repository or mature enough to be promoted out of one.

The README opens by tracing that arrangement back to the RocketMQ Improvement Proposal, which is how community contributions were collected and maintained rather than folded into the broker itself. The PMC's stated position is that it leans towards developer community support to help discovery and the first steps towards incubation. In practice that means the list is curated and the governance is light. Nothing in this repository compiles into a service you can run, and there are no GitHub releases on the project at all, so there is no version line to pin against.

That makes it a different kind of artifact from the rest of a broker's tooling. RocketMQ itself is the product. This page is the index that tells you which satellite project to go read next.

Graduated and incubator lists tell you where support sits

The README splits the catalogue into two labelled groups, and the split is more informative than it looks. The graduated projects are the language clients and the Spring integration: RocketMQ Client CPP, RocketMQ Client Python, RocketMQ Spring and RocketMQ Client Go. Each has moved to its own repository under the Apache organization, which is the outcome the graduation criteria describe.

Those criteria are written out in the README, and they are a fair summary of what Apache incubation means. A project needs a three plus one vote from the PMC, it needs to have been used successfully in production by at least three independent end users that the PMC judges to be of adequate quality and scope, and it needs a healthy number of committers. The third criterion is the one people forget: incubation is partly a statement about the people behind the code, not only about the code.

Below that line sit the incubator projects, and their descriptions are one line each. RocketMQ Dashboard, RocketMQ MQTT, RocketMQ-Flink, RocketMQ Streams, RocketMQ Operator, RocketMQ Client Nodejs, RocketMQ-Docker, RocketMQ-Exporter, RocketMQ-Connect, RocketMQ-Flume, RocketMQ-Spark, RocketMQ-JMS and RocketMQ-MySQL. Two of those descriptions carry a notice that the project has moved to a new repository and will be removed from this one: Flink and the dashboard, the latter renamed from Console.

What the tree still holds that the README has already given up

The mismatch between the README's list and the actual tree is where the useful detail lives. Several submodules are present as directories: `rocketmq-flume/`, `rocketmq-hbase/`, `rocketmq-jms/`, `rocketmq-knative/`, `rocketmq-mysql/`, `rocketmq-redis/`, `rocketmq-rocksdb/`, `rocketmq-sentinel/`, `rocketmq-serializer/`, `rocketmq-spark/`, `rocketmq-tieredstore-s3/`, `rocketmq-iot-bridge/`, `rocketmq-beats-integration/`, `rocketmq-logstash-integration/` and `rocketmq-cloudevents-binding/`.

Meanwhile Flink, Dashboard, Docker, Exporter, Connect, Streams, Operator and the Node client are all linked out to their own repositories, and there is no directory here for any of them. So the set of things you can actually read in this tree is narrower than the set of things the page advertises, and narrower than the set the README describes.

A few of the in-tree names tell you something specific about scope. `rocketmq-tieredstore-s3` suggests tiered message storage backed by object storage, `rocketmq-rocksdb` suggests a storage engine other than the default, `rocketmq-sentinel` points at the flow control and circuit breaking project most Java developers know from the same ecosystem, and `rocketmq-knative` and `rocketmq-cloudevents-binding` are eventing work rather than messaging work. There is also `rocketmq-ansible/` for deployment, `tools/` for developer utilities, and a `.travis.yml` as the only CI configuration at the root.

Reading the pages inside the repository when a project needs setup

Only two submodules are documented in the README itself, through links to README files inside the tree. RocketMQ-Spark gets a pointer for details, with the note that both push and pull consumers are provided, and RocketMQ-MySQL gets a pointer describing itself as a data replicator between MySQL and other systems. Both of those are integrations where the consumer model genuinely changes how you write the job, so the one line of documentation is the honest minimum.

Under `docs/`, the single named file is the Chinese-language user guide for RocketMQ Connect. Connect is the project's answer to the Kafka Connect style framework, and the README's summary of it is one clause: a connector to connect everything. A connector framework is exactly the kind of thing where documentation carries most of the design, and the repository keeps only one guide for it, in Chinese, with the English equivalent living in the separate connect repository.

There is no root README section covering build steps, because there is nothing to build at the top level. If you arrived looking for a clone-and-run path, the honest answer is that this repository has never been one. Follow a submodule link, or work with a satellite project's own documentation, where the install steps will be.

The operator, exporter and IoT pieces cover the deployment gaps

Three of the linked projects address gaps that a broker does not fill on its own, and they are the ones worth reading about before you pick a deployment strategy.

RocketMQ Operator deploys the broker on Kubernetes using the Operator SDK, part of the Operator Framework, and is listed on OperatorHub. RocketMQ-Exporter exports metrics from RocketMQ servers for Prometheus, which is the missing piece in most broker monitoring setups. RocketMQ-Docker provides Dockerfiles and bash scripts for building and running an image, which predates the operator and remains a faster path for a laptop or a single test environment.

The MQTT project is the one with a real architectural claim attached. The README describes it as a new MQTT protocol architecture model built on RocketMQ's unified message storage engine, so that both MQTT terminals and servers can send and receive. That matters for IoT and mobile clients, because it means device traffic stays in the same storage system as server traffic instead of going through a separate broker.

The Others section points out three integrations that live elsewhere entirely: RocketMQ with OpenTelemetry in the opentelemetry-java-instrumentation repository, RocketMQ-Ignite as an Apache Ignite extension module, and RocketMQ-Storm inside the Storm repository's external directory. Confetti is the honest word for where these end up.

How this compares with the integration story around Kafka or RabbitMQ

The question people bring to this page is usually about RocketMQ itself rather than its satellites, and the structural difference is the interesting part. Kafka's ecosystem grew the other way round: the connect framework and the schema registry took shape inside the main project, and the surrounding tools assume a single canonical home. RabbitMQ has a smaller surface because it never needed a Java client to be built from scratch.

The RocketMQ community spread outward instead. Four language clients had to exist before the broker was usable outside Java, so they became separate projects first and graduated on their own schedules. Connectors, exporters and the operator followed the same path, which is why this README reads like a catalogue with graduation statuses rather than a feature list.

The practical consequence for anyone evaluating the ecosystem is that maturity varies sharply between links on the page, and the only signal the page gives you is the graduated or incubator label plus whether a project has already moved out to its own repository. Check the individual project's own repository for release history before committing to it in production. The last push here was on 2026-09-04, and no licence file is listed at the root, so the terms of any satellite project need confirming in that project's own repository rather than here.

Editorial conclusion

This repository earns its keep as a directory rather than a dependency. If you need a Go client, a Prometheus exporter or a Flink connector, the README tells you which repository to look at and whether that project has graduated, and that is faster than guessing from search results. It will not help you install anything: there is no build here for the broker, no release stream, and the submodules are uneven, with Flink and the dashboard already moved out while Flume, HBase and Redis remain in the tree. Point at the specific project you need, check whether its own repository still lists releases, and treat the Apache-2.0 status of RocketMQ itself as a statement about the broker rather than about every project linked from this page.

Frequently asked questions

Official sources

1. apache/rocketmq-externals on GitHub
2. Issues
3. README