RabbitMQ

What is RabbitMQ?

RabbitMQ is an open-source message broker that receives, routes, temporarily stores and reliably delivers messages between applications, so that systems can communicate asynchronously and remain loosely coupled. The broker was built around AMQP 0-9-1 and also supports AMQP 1.0, MQTT, STOMP and its own stream protocol. In OT convergence, where IT applications and OT systems share data, RabbitMQ often sits between SCADA, MES, ERP, historians and cloud applications, so that a failure in one system does not immediately affect the others.

🧠 Where does RabbitMQ come from and who maintains it?

RabbitMQ was released in 2007 by Rabbit Technologies, a joint venture between LShift and CohesiveFT. In April 2010 SpringSource, then part of VMware, acquired the project. It moved to Pivotal in 2013 and returned to VMware at the end of 2019. Since Broadcom acquired VMware in November 2023, RabbitMQ has been part of Broadcom, which offers a commercial edition (Tanzu RabbitMQ) with longer support alongside the free open-source version.

The server is written in Erlang on the Open Telecom Platform (OTP), a runtime originally developed for telephone exchanges that excels at handling many concurrent connections and isolating faults. The source code is licensed under the Mozilla Public License 2.0.

Mind the lifecycle: a release series receives roughly nine months of free community support. If you want to stay on one version for longer, which is common in OT, you need a commercial contract or a patching cadence designed around it.

🔧 How does RabbitMQ work?

RabbitMQ places a broker in the middle. A producer never sends a message directly to a queue, but to an exchange. Based on bindings and a routing key, the exchange decides which queue or queues receive the message. A consumer fetches the message from there and confirms processing with an acknowledgement; only then does the broker delete it.

RabbitMQ has four basic exchange types, found in almost every installation:

Less common types also exist, such as the local random exchange, which delivers a message to a queue on the local node, and, via plugins, the consistent hashing exchange for spreading messages across queues. In addition, the broker supports work queues (distributing tasks across several consumers), publish-subscribe, request-reply and dead-letter exchanges for messages that cannot be processed.

🔄 Which queue types exist and when do you use which?

Modern RabbitMQ versions offer three kinds of storage. Your choice determines how reliable and how fast a data flow is.

Streams keep messages until a retention rule (max-age, for example 7D, or max-length-bytes) removes them. A consumer can read from the start, from the end, from an offset or from a point in time. This means RabbitMQ can replay data as well, something that used to be the preserve of Apache Kafka.

The old classic mirrored queues were removed in version 4.0. For high availability you now use quorum queues or streams on a cluster of three or five nodes; with three nodes one may fail, with five two.

🌐 Which protocols and ports does RabbitMQ use?

By default, MQTT messages arrive at the topic exchange amq.topic. RabbitMQ translates the MQTT separator / into . and the wildcard + into *, so the MQTT topic plant/line1/temp continues as routing key plant.line1.temp. This lets MQTT sensors and AMQP applications share the same data. One limitation: retained MQTT messages are not replicated between nodes. If you need a full-featured MQTT broker, also look at Mosquitto or a broker with Sparkplug B support.

📡 Where do you place RabbitMQ in an OT architecture?

RabbitMQ belongs above real-time control. In the Purdue Model the broker sits at level 3 (operations, alongside MES and the historian), in the IDMZ at level 3.5 as a relay to the business network, or at level 4 and in the cloud. It does not belong at levels 0 to 2: the broker is not deterministic, its latency depends on load and disk, and a broker restart must never stop a machine. Real-time control therefore stays with fieldbuses such as PROFINET, IP and EtherCAT.

That separation from control is exactly its strength: scalability and fault isolation without risk to the process. A common pattern is one broker per site at level 3 that collects data from SCADA and edge gateways, plus a shovel or federation link that forwards messages through the IDMZ to a central broker. If the WAN or cloud connection drops, the local queues buffer the messages and production simply carries on. This matches the ISA-95 separation between control, operations and business planning.

🔐 How do you secure RabbitMQ in an OT environment?

A broker that connects SCADA, MES and the cloud is an attractive cybersecurity target: anyone with access can read or forge messages, or flood queues. Key measures:

• Remove the guest account - since version 3.3, guest can only log in from localhost, but in production the account should be deleted.
• TLS ports only - close 5672, 1883 and 15672 and use 5671, 8883 and 15671, preferably with client certificates and proper certificate management.
• Minimal permissions - give every application its own user and virtual host with configure, write and read permissions only on its own exchanges and queues (Least Privilege, RBAC).
• Central identities - connect to LDAP or, via the OAuth 2.0 plugin, to an identity provider; MFA for administrators is enforced in that identity provider, as RabbitMQ itself has no MFA.
• Protect the management interface and cluster ports - ports 15672, 25672 and 4369 must never be reachable from the production network or the internet.
• Set limits - memory and disk alarms, maximum queue lengths and connection limits prevent one faulty producer from taking down the broker.
• Monitor and log - send logs to your SIEM and track metrics such as queue length, unacknowledged messages and connections per user.

Place the broker in its own zone according to IEC 62443, with conduits to the zones it serves, and apply Defense in Depth and Zero Trust: every client authenticates, every connection is encrypted and only the required ports are open in the DMZ or IDMZ. For organisations covered by the Dutch Cybersecurity Act (Cyberbeveiligingswet), in force since 15 August 2026, the broker is simply part of the network and information systems subject to the duty of care and patch management. For the governance around it, ISO 27001, the NIST CSF and the OT guidance NIST SP 800-82 apply.

🧩 What is the difference between RabbitMQ and Apache Kafka?

In practice they complement each other: RabbitMQ handles commands and messages per site, while Kafka collects large event streams centrally for analysis. For a Unified Namespace, many plants start with an MQTT broker and add RabbitMQ or Kafka where routing or long-term retention is needed.

🏭 How do you roll out RabbitMQ in a plant step by step?

1. Map the data flows - which systems send what, how often, and how critical is loss?
2. Choose a queue type per flow - quorum queues for orders and alarms, streams for telemetry, classic queues only for disposable data.
3. Design a routing key naming scheme - for example site.line.machine.type, so topic exchanges can be extended later.
4. Build a three-node cluster - on separate hardware or Kubernetes nodes, with an odd number for the quorum.
5. Secure it from day one - TLS, a separate user per application, separate virtual hosts and firewall rules in the IDMZ.
6. Set up monitoring - Prometheus metrics into Grafana, with alerts on queue length and disk alarms.
7. Plan the lifecycle - record in your lifecycle management when you move to a new release series, and test upgrades on an acceptance cluster first.
8. Test failures - shut down a node or the WAN link and check that messages are buffered and then delivered correctly.

An example: a food manufacturer routes SCADA alarms through a topic exchange to a quorum queue for the maintenance system, sends machine counters through a stream to a historian and an OEE dashboard, and receives production orders from the ERP through a direct exchange per line. If the cloud connection drops for an hour, only the queues grow; the lines keep running.

❓ Frequently asked questions

Is RabbitMQ free?

RabbitMQ is open source under the Mozilla Public License 2.0 and free to use, including commercially. Broadcom also offers Tanzu RabbitMQ with paid support and longer maintenance periods per version. For OT environments that want to stay on one version for a long time, that longer support is often the main argument.

Can RabbitMQ handle MQTT messages?

Yes, RabbitMQ supports MQTT 3.1, 3.1.1 and, since version 3.13, MQTT 5.0 through a plugin that ships with the core distribution. MQTT messages arrive at the topic exchange amq.topic, so AMQP applications can receive the same data. However, RabbitMQ does not replicate retained messages between cluster nodes.

Is RabbitMQ suitable for real-time machine control?

No, RabbitMQ is not deterministic and therefore does not belong in the control levels of the Purdue model. The broker is intended for integration at level 3 and above, such as alarm distribution, orders and telemetry. Real-time control stays with PLCs and fieldbuses such as PROFINET, EtherNet/IP and EtherCAT.

What are quorum queues in RabbitMQ?

Quorum queues are queues that are replicated across several nodes using the Raft algorithm and have been available since version 3.8. A message only counts as stored once a majority of nodes have it, so losing one node in a three-node cluster costs no data. Since RabbitMQ 4.0, quorum queues are the successor to the removed classic mirrored queues.

Can RabbitMQ replay messages like Kafka?

Yes, with streams, available since version 3.9, RabbitMQ keeps messages in an append-only log until a retention rule removes them. A consumer can then reread from the start, an offset or a point in time. For very large, long-lived event archives, Apache Kafka usually remains the more common choice.

Which ports do you need to open for RabbitMQ?

For secured clients these are usually 5671 for AMQP over TLS, 8883 for MQTT over TLS and 15671 for the management UI over HTTPS. You should preferably close the unencrypted ports 5672, 1883 and 15672. Cluster ports 25672 and 4369 should only be open between the RabbitMQ nodes themselves.

📌 In summary

RabbitMQ is an open-source message broker that reliably routes, buffers and delivers messages between systems through exchanges and queues. In IT/OT environments, RabbitMQ connects SCADA, MES, ERP, historians and the cloud at level 3 and above, with quorum queues for critical messages, streams for telemetry and replay, and AMQP and MQTT as the main protocols. Place the broker in its own zone, use TLS and minimal permissions only, and keep the short support window per version in mind in your patching policy.