RabbitMQ earns its place when routing matters as much as storage
RabbitMQ accepts messages from producers and delivers them to consumers through exchanges, queues, bindings, and streams. That vocabulary gives application teams more routing control than a basic pub-sub server: direct, topic, fanout, and header-based patterns can live at the broker instead of being repeated in every service. The server supports AMQP 1.0, AMQP 0-9-1, RabbitMQ Stream Protocol, MQTT 3.1 through 5.0, and STOMP 1.0 through 1.2, including several WebSocket transports.
The repository shows the cost of that range. Our commit 67c1bfa checkout contained 3,558 files and about 55,565 lines of source, occupying 61.3 MB before the Selenium dependencies were installed. It includes the core server and tier-one plugins for management, federation, shovel, MQTT, STOMP, streams, OAuth, LDAP, Prometheus, and several discovery systems. Teams can run one product for many messaging jobs, but upgrades and incident reviews must account for the plugins actually enabled.
Version 4.3.5 is active and requires Erlang 27
RabbitMQ is maintained like infrastructure rather than a weekend repository. GitHub recorded a push on August 29, 2026, and release 4.3.5 had shipped on August 17. That maintenance release fixes quorum recovery, mixed-version queries, AMQP frame handling, MQTT parsing, shovel failures, and management behavior. The issue tracker had 202 open issues and 64 open pull requests when fetched. Those counts show current work and reporting volume; they do not mean the broker has 266 confirmed bugs.
Release discipline also creates an upgrade obligation. Version 4.3.5 requires Erlang 27.0 or newer, and its notes say older runtimes will not start. The same release warns operators to enable encrypted management credentials only after every node in a rolling upgrade understands them. Our lab did not attempt that path. It used a 3-CPU, 8 GB unprivileged container and measured only commit 67c1bfa's Node-based Selenium project, so none of these release fixes received runtime verification from us.
What happened when we ran it
Our sandbox entered ./selenium, installed 240 npm packages in 43 seconds, and used 63 MB for them. Npm audit reported 0 known vulnerabilities across all severity levels. The package defines no build script, so the harness skipped that step. These are useful facts about the management and authentication browser-test tooling, not about installing Erlang packages or starting a message broker.
The test command failed with exit code 1 after 7 seconds. Its final lines show Node's CommonJS and ESM loaders passing control into Mocha's file loader and command runner. The supplied log has no summary lines and does not include the originating exception, so it does not establish whether a module, environment value, browser, or service caused the failure. We can say only that the Selenium suite did not start cleanly enough to report tests in this fresh container.
The production checklist is longer than the quick install
Official packages, container images, and a Kubernetes operator spare most users from compiling the repository. A useful deployment still needs persistent volumes, stable node identity, users and permissions, TLS choices, memory and disk alarm thresholds, metrics, and backups of definitions and data where applicable. Quorum queues add replication for workloads that need it, while streams retain an append-only log for replaying consumers. The right queue type depends on failure tolerance and consumption pattern, so the default should be chosen deliberately.
Source contributors face a different setup. RabbitMQ's guide says the core server suites alone can take 30 to 40 minutes on a recent multi-core machine and describes separate targets for quorum queues, queue parallelism, and log management. Selenium adds Docker, a browser, generated environment files, and optional services such as Keycloak, UAA, LDAP, proxies, and extra broker nodes. The 18 CI workflow files in our checkout make that breadth visible, even though our short Node run did not reproduce the CI environment.
One local cluster should not cross a wide-area link
RabbitMQ clusters coordinate broker state closely. The clustering guide expects LAN-like links and directs distant sites toward federation or shovel, which tolerate intermittent connections and independent clusters. That is a meaningful design boundary for multi-region systems. Treating three distant nodes as one cluster may look simpler on a diagram, but it puts latency and partitions into the mechanism that keeps broker members coordinated. Regional clusters with explicit message movement are easier to reason about during an outage.
The choice against Kafka, Pulsar, or NATS should begin with workload shape. RabbitMQ is persuasive when per-message routing, acknowledgements, work queues, and mixed protocols are central. Kafka is built around a retained partitioned log, Pulsar separates serving and storage, and NATS offers a smaller messaging core with optional persistence. Our failed 7-second Selenium run is a reason to recheck the exact source commit before contributing. It is not a reason to dismiss a broker with a current 4.3.5 maintenance line and active issue work.