RabbitMQ server on a dedicated machine, from the production checklist

What a RabbitMQ node needs

RabbitMQ's Production Deployment Guidelines set a floor per node and warn that the broker was not designed for a single CPU core or for sharing a host with other disk- and network-heavy tools. The table holds the documentation's own figures.

The checklist's worked example, 20,000 messages a second at 6 KB each, needs 1.056 Gbit/s: more than a 1 Gbps port. Our arithmetic: on 32 GB the default watermark blocks publishers near 19 GB.

Ports, and which ones leave the machine

The production checklist's firewall section splits the ports in two: client-library ports, which application hosts must reach, and the rest (inter-node traffic, CLI tools), limited to hosts running nodes or CLI tools. The Networking guide adds that 25672 should not be publicly exposed. Loopback listeners plus ufw's default deny apply that split.

epmd listens on every interface unless ERL_EPMD_ADDRESS limits it, so here the firewall keeps 4369 private. Plugin ports (streams 5552, Prometheus 15692) open only with their plugins. Each of our machines has one connected port and no private VLAN is sold, so cluster peers talk over public addresses: open 4369 and 25672 (and 35672-35682 if CLI tools run from another node) only to the other nodes' IPs, 5671 only to app servers, and use TLS between nodes as the guidelines recommend.

Which machines fit

One node per machine, with nothing else storing data beside it, is the shape the guidelines describe, and it is what a dedicated server gives you: the whole machine's cores, memory and disks, root, and an unmetered port with no transfer allowance. Use x86-64 lines: the Erlang packages this page installs are amd64-only. The Ampere Altra line would need Team RabbitMQ's arm64 Erlang from Launchpad, not covered here, and X-Gene boots nothing newer than Ubuntu 18.04.

• Single-socket rack servers for one broker in front of a few applications, each with a full out-of-band console (HPE iLO, Dell iDRAC or a Supermicro BMC).
• Dual-socket rack servers (Xeon E5-2630L v3, E5-2650L v2, Gold 6130) when connection and queue counts climb.
• Three identical machines in one city for a quorum-queue cluster: the guidelines call for an odd node count.
• An NVMe cartridge from the NVMe line for a dev or QA broker. Among cartridges, the m510 and m710x each carry a console of their own; the others offer power control alone.

The rack and blade lines carry a hardware RAID controller; no Moonshot cartridge does. Past a gigabit, a 10 Gbps port is offered on the lines that take it. Cache and database belong on their own machines too: Redis on its own server and PostgreSQL on its own server. Racked machines arrive in about 30 minutes, counted from payment approval; builds to order take 4 to 24 hours.

Installing from the Team RabbitMQ repositories

The Debian and Ubuntu guide says to avoid the distribution's own rabbitmq-server package, usually many releases behind and often past end of life, and to take Erlang and the server from Team RabbitMQ's apt repositories. Supported: Ubuntu 22.04, 24.04, 26.04 and Debian 11 to 13; 26.04 uses the noble repository. Below is the guide's quick-start script with these edits of ours: it runs as root without sudo, refuses anything but amd64 Ubuntu 24.04/26.04, refreshes apt first, writes the four repository lines with a loop instead of a heredoc (plus pipefail), ends with a rabbitmq-diagnostics -q ping that prints installed or STOP, and enables ufw first, because the package starts the node during install, listening on every interface. Re-running it is harmless.

# Ubuntu 24.04 or 26.04 on amd64, as root. The firewall goes on first: the package starts the node while it installs.
set -o pipefail
if [ "$(dpkg --print-architecture)" != amd64 ]; then echo "STOP - these repositories carry amd64 Erlang only"
elif ! grep -qE '^VERSION_ID="(24|26)\.04"' /etc/os-release; then echo "STOP - this block is for Ubuntu 24.04 or 26.04"
else
sed -i 's/^IPV6=.*/IPV6=yes/' /etc/default/ufw && ufw allow OpenSSH && ufw --force enable &&
apt-get update -y && apt-get install -y curl gnupg apt-transport-https &&
curl -1sLf "https://keys.openpgp.org/vks/v1/by-fingerprint/0A9AF2115F4687BD29803A206B73A36E6026DFCA" | gpg --dearmor > /usr/share/keyrings/com.rabbitmq.team.gpg &&
for r in rabbitmq-erlang rabbitmq-server; do for m in deb1 deb2; do
  echo "deb [arch=amd64 signed-by=/usr/share/keyrings/com.rabbitmq.team.gpg] https://$m.rabbitmq.com/$r/ubuntu/noble noble main"
done; done > /etc/apt/sources.list.d/rabbitmq.list &&
apt-get update -y &&
apt-get install -y erlang-base erlang-asn1 erlang-crypto erlang-eldap erlang-ftp erlang-inets \
  erlang-mnesia erlang-os-mon erlang-parsetools erlang-public-key erlang-runtime-tools erlang-snmp \
  erlang-ssl erlang-syntax-tools erlang-tftp erlang-tools erlang-xmerl &&
apt-get install -y rabbitmq-server --fix-missing &&
rabbitmq-diagnostics -q ping && echo "installed" || echo "STOP - the install did not finish, read the output above"
fi

On Ubuntu 22.04 change both noble words to jammy and (24|26) in the version check to 22. The node runs as the rabbitmq user and logs to /var/log/rabbitmq. A guest user (password guest) exists now, but it can only log in over loopback.

Configuration: listeners, alarms and file limits

Next, /etc/rabbitmq/rabbitmq.conf pins AMQP and the management listener to loopback, removes the ANONYMOUS login mechanism as the checklist advises for production, keeps the 60% memory watermark and lifts the disk alarm from 50 MB. The disk figure is our arithmetic: 60% of installed RAM, rounded up to whole GB, after the checklist's advice to match the memory watermark. The systemd drop-in sets 65536 open files, the Debian guide's production minimum.

# As root, once the install block has printed "installed". Refuses to overwrite an existing config.
C=/etc/rabbitmq/rabbitmq.conf
if [ -e $C ]; then echo "STOP - $C already exists, merge these lines by hand"
else
G=$(awk '/^MemTotal/ {printf "%d", $(NF-1) * 1024 * 0.6 / 1000000000 + 1}' /proc/meminfo) && [ "$G" -gt 1 ] &&
rabbitmq-plugins enable rabbitmq_management &&
cat > $C <<EOF &&
listeners.tcp.1 = 127.0.0.1:5672
listeners.tcp.2 = ::1:5672
management.tcp.ip = 127.0.0.1
auth_mechanisms.1 = PLAIN
auth_mechanisms.2 = AMQPLAIN
anonymous_login_user = none
vm_memory_high_watermark.relative = 0.6
disk_free_limit.absolute = ${G}GB
EOF
mkdir -p /etc/systemd/system/rabbitmq-server.service.d &&
printf '[Service]\nLimitNOFILE=65536\n' > /etc/systemd/system/rabbitmq-server.service.d/limits.conf &&
systemctl daemon-reload && systemctl restart rabbitmq-server &&
rabbitmq-diagnostics -q check_running && L=$(rabbitmq-diagnostics -s listeners) && echo "$L" &&
echo "$L" | grep -q 'Interface: 127.0.0.1, port: 15672' &&
! echo "$L" | grep -Eq '(\[::\]|0\.0\.0\.0), port: (5672|15672),' &&
echo "loopback only" || echo "STOP - read the listener list above before going on"
fi

With less free space than that limit on the disk holding /var/lib/rabbitmq, the node raises a disk alarm at once and blocks publishers. If the block stops after writing the file, fix the reported problem, move the file aside (mv /etc/rabbitmq/rabbitmq.conf /root/rabbitmq.conf.half) and run the block again.

Remote applications connect over TLS. Put a certificate, key and CA bundle readable by rabbitmq under /etc/rabbitmq/tls/, add listeners.ssl.default = 5671 and the three ssl_options file keys from the TLS guide, restart, and open the port per host: ufw allow from 203.0.113.10 to any port 5671 proto tcp.

Users, virtual hosts and the nightly export

The checklist says to delete guest in production and give every application a separate user. The block makes an administrator and an application user in an orders vhost (rename both), passes generated hex passwords on standard input as the access-control guide shows, saves them in a mode-600 file and deletes guest last. It then writes a cron job that exports definitions nightly, checks the JSON, archives the config and prunes copies older than 30 days only after a good run.

# As root. An admin, one app user in its own vhost, then guest goes. Refuses a second run.
K=/root/rabbitmq-credentials.txt; B=/var/backups/rabbitmq
if [ -e $K ]; then echo "STOP - $K exists, the users were made already"
else
A=$(openssl rand -hex 24) && P=$(openssl rand -hex 24) && [ -n "$A" ] && [ -n "$P" ] &&
install -m 600 /dev/null $K && printf 'admin %s\norders-app %s\n' "$A" "$P" > $K &&
rabbitmqctl add_vhost orders &&
echo "$A" | rabbitmqctl add_user admin && rabbitmqctl set_user_tags admin administrator &&
rabbitmqctl set_permissions -p / admin ".*" ".*" ".*" &&
rabbitmqctl set_permissions -p orders admin ".*" ".*" ".*" &&
echo "$P" | rabbitmqctl add_user orders-app &&
rabbitmqctl set_permissions -p orders orders-app ".*" ".*" ".*" &&
rabbitmqctl delete_user guest &&
install -d -m 700 -o rabbitmq -g rabbitmq $B &&
printf '%s\n' 'SHELL=/bin/bash' 'PATH=/usr/sbin:/usr/bin:/sbin:/bin' \
 '20 3 * * * root umask 077; B=/var/backups/rabbitmq; T=$(date +\%F-\%H\%M\%S); rabbitmqctl -q export_definitions $B/defs-$T.json && python3 -m json.tool $B/defs-$T.json > /dev/null && tar -czf $B/etc-$T.tgz -C / etc/rabbitmq etc/systemd/system/rabbitmq-server.service.d etc/cron.d/rabbitmq-backup && tar -tzf $B/etc-$T.tgz > /dev/null && find $B -name "defs-*" -mtime +30 -delete && find $B -name "etc-*" -mtime +30 -delete || echo "$T backup FAILED" >> $B/errors.log' \
 > /etc/cron.d/rabbitmq-backup &&
rabbitmqctl list_users && echo "users done" || echo "STOP - see the error above"
fi

Reach the management UI through your own login, ssh -L 15672:127.0.0.1:15672 you@server, then http://localhost:15672. If the block stopped part-way, rabbitmqctl list_users shows what exists: complete the rest by hand with the saved passwords, or delete those users and the file and run it again. Exports hold password hashes, so treat them as sensitive. Copy /var/backups/rabbitmq off the machine yourself, plus /root/rabbitmq-credentials.txt, which the archive skips (or keep those passwords in a password manager).

Restoring, and what an export leaves out

An export rebuilds users, vhosts, permissions, policies, queues, exchanges and bindings, not queued messages. The Backup and Restore guide discourages copying message directories from a running node: stop it first and copy /var/lib/rabbitmq/mnesia, and since 3.8 that copy restores only onto a node with the identical node name. To rebuild from an export, as root:

1. Install with the first block only, then install -d -m 700 -o rabbitmq -g rabbitmq /var/backups/rabbitmq and copy one night's pair into it (T is its timestamp).
2. Instead of the configuration block: cd /var/backups/rabbitmq && tar -tzf etc-T.tgz > /dev/null && tar -xzf etc-T.tgz -C / && systemctl daemon-reload && systemctl restart rabbitmq-server. The cron file comes back with it.
3. Importing over definitions you want to keep? Export them first to a file of their own, so there is a way back.
4. Then python3 -m json.tool /var/backups/rabbitmq/defs-T.json > /dev/null && rabbitmqctl import_definitions /var/backups/rabbitmq/defs-T.json, delete the fresh guest user, and put your saved copy of the credentials file back in /root at mode 600.
5. ufw rules are not in the archive: re-add ufw allow from 203.0.113.10 proto tcp to any port 5671 for each app host, and the peer rules for a cluster.

Upgrades

RabbitMQ 4.4.0 shipped on 20 October 2026, takes Erlang 27.0 to 29.x, and supports rolling upgrades only from 4.2 or 4.3. The Upgrade guide treats one node like a cluster.

• First rabbitmqctl enable_feature_flag all; the guide says an upgrade may fail without stable feature flags on. Then rabbitmq-diagnostics -q check_local_alarms and a fresh export.
• Stop the node and upgrade Erlang with RabbitMQ: systemctl stop rabbitmq-server && apt-get update && apt-get upgrade (it updates every other package too). Start the node if the package has not, and check again.
• To control when a new series arrives, pin packages with apt preferences as the Debian guide shows.

Licence and honest limits

The LICENSE file in the rabbitmq-server repository puts the server and its tier 1 (core) plugins under MPL 2.0 (Mozilla Public License, version 2.0), with some OCF files under Apache 2.0. Our general reading, not legal advice: MPL 2.0 is file-level copyleft with no network clause, so running the broker for your own systems or behind a service you sell owes nobody source. Distribute RabbitMQ, modified or not, and the MPL-covered files, including your changes to them, must also be available as source under the MPL; your own code in separate files keeps its own licence.

One node is one point of failure: the guidelines put single nodes at development, testing and some QA; three nodes survive losing one. You run the broker yourself here, so someone must watch alarms, file descriptors and disk.