How to set up a RabbitMQ cluster

A RabbitMQ cluster is a group of RabbitMQ nodes that share users, queues, exchanges, bindings, and runtime state so they behave as a single logical message broker. Running RabbitMQ as a cluster gives you high availability and room to scale: if one node fails, the others keep accepting and delivering messages. This guide walks through installing, connecting, and testing a multi-node cluster.

Sending webhooks?

Svix is the enterprise-ready webhook sending service. It handles signing, retries, and delivery observability, so you can ship a reliable webhook platform in minutes instead of months. Start sending webhooks with Svix.

When you need a RabbitMQ cluster

A single RabbitMQ node is a single point of failure. If it goes down, publishers and consumers lose their broker and messages stop flowing. Clustering spreads users, exchanges, and queue metadata across several nodes so the broker survives the loss of any one machine, and it lets you add nodes to handle more connections and throughput. If you are only running a development instance or a low-volume service, one node is simpler and often enough.

Setting up the cluster

Prerequisites

• Two or more machines (physical or virtual) running a compatible OS (e.g., Linux/Unix, Windows).
• RabbitMQ installed on all machines.
• Network connectivity between all machines.

Step 1: Install RabbitMQ

Install the same RabbitMQ and Erlang versions on every node, using the official installation guide or one of our platform walkthroughs for Ubuntu, macOS, Windows, or Docker. Mismatched versions can refuse to cluster.

Step 2: Configure hostnames

Each node needs a unique hostname, and every machine must be able to resolve the hostnames of all the others. Update /etc/hosts or your DNS so the nodes can reach each other by name:

# Example /etc/hosts entries
192.168.1.101 rabbitmq-node1
192.168.1.102 rabbitmq-node2

Step 3: Share the Erlang cookie

Nodes authenticate to each other with a shared secret called the Erlang cookie. If the values differ, join_cluster fails with an authentication error, which is the most common reason a cluster refuses to form. Copy the file from the first node to the others and keep its permissions tight:

# On rabbitmq-node1, read the value
sudo cat /var/lib/rabbitmq/.erlang.cookie

# On every other node, with RabbitMQ stopped
echo "PASTE_COOKIE_VALUE" | sudo tee /var/lib/rabbitmq/.erlang.cookie
sudo chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie
sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie

The nodes also need TCP 4369 (the port mapper) and 25672 (inter-node traffic) reachable between them, plus 5672 for clients and 15672 for the management UI.

Step 4: Set up RabbitMQ nodes

Start RabbitMQ on all nodes:

rabbitmq-server start

Optionally, enable the RabbitMQ management plugin (highly recommended):

rabbitmq-plugins enable rabbitmq_management

Step 5: Form the cluster

Stop RabbitMQ on nodes that will join the cluster (except the first node):

rabbitmqctl stop

Join each node to the cluster. On each node (except the first one), run:

rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@rabbitmq-node1
rabbitmqctl start_app

Replace rabbitmq-node1 with the hostname of the node you want to join.

Verify the cluster status:

rabbitmqctl cluster_status

Step 6: Configure high availability

Clustering replicates metadata across nodes, but queue contents live on one node unless you make the queue itself replicated. On modern RabbitMQ (3.8 and later), use quorum queues, which replicate messages across nodes using a consensus protocol and survive a node failure without data loss. Queue type is chosen when the queue is declared, by passing the x-queue-type argument:

rabbitmqadmin declare queue name=orders queue_type=quorum durable=true

Older guides use classic mirrored queues (a ha-mode: all policy), but mirroring is deprecated and removed in RabbitMQ 4.0, so new clusters should use quorum queues instead.

Step 7: Test the cluster

Publish and consume messages to confirm they are routed correctly no matter which node the client connects to. Then test failover: stop RabbitMQ on the node hosting a quorum queue's leader, publish again, and confirm a new leader was elected and no messages were lost.

Keeping the cluster healthy

A cluster is not set-and-forget. Watch node health, memory and disk alarms, and queue depth so a struggling node does not drag down the rest, which our guide to RabbitMQ monitoring walks through, and put a load balancer in front of the nodes so clients reconnect to a healthy one when a node drops. For most clusters, three nodes is the practical minimum: quorum queues need a majority to stay available, so three nodes tolerate the loss of one.

The steps above adapt to larger clusters, different network setups, and integration with the rest of your stack. If your goal is reliable event delivery to your own users rather than operating broker infrastructure yourself, a managed webhook service like [Svix]https://www.svix.com/?utm_source=resources&utm_medium=content) handles the queueing, retries, and monitoring for you.