Install RabbitMQ on a VPS: Setup, Users & Firewall Rules
A common ticket we get from customers running Node, Python, or Laravel apps on a VPS: "I set up RabbitMQ, my worker connects fine, but I keep getting ACCESS_REFUSED from anything outside the server" — or the opposite problem, someone left the default guest account open to the internet and found unfamiliar queues in the management UI a week later. RabbitMQ isn't hard to run, but the defaults are built for local development, not production. Here's how to install it properly on a fresh Ubuntu VPS, lock it down, and fix the errors you'll actually hit.
Installing RabbitMQ
RabbitMQ needs Erlang underneath it, and version mismatches between the two are the single biggest source of weird startup failures. The simplest reliable path on Ubuntu is to install both from the distro's own repos, which keeps the versions paired correctly:
sudo apt update
sudo apt install -y erlang-base rabbitmq-serverUbuntu's repo version can lag a release or two behind upstream. That's fine for most workloads — if you specifically need the latest RabbitMQ release for a feature or CVE fix, use the official install script from RabbitMQ's own documentation instead of mixing repos halfway, since a partial Erlang/RabbitMQ version mismatch is exactly what causes the startup crashes support tickets are usually about.
Start it and make sure it survives a reboot:
sudo systemctl enable --now rabbitmq-server
sudo systemctl status rabbitmq-serverTurn on the management plugin — it gives you a web UI on port 15672 for queues, connections, and users, which saves a lot of guesswork later:
sudo rabbitmq-plugins enable rabbitmq_managementLock down the default guest account first
Fresh RabbitMQ ships with a guest/guest account that has full admin rights on the default vhost. By design, RabbitMQ only allows guest to log in from localhost — it won't authenticate over a remote connection even if you open the port. That's a safety net, not a real fix. Bots and scanners still probe for management UIs left open with weak credentials on other accounts, so don't rely on the localhost restriction as your only defense.
Create a real admin user and delete guest entirely:
sudo rabbitmqctl add_user admin 'a-strong-password-here'
sudo rabbitmqctl set_user_tags admin administrator
sudo rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"
sudo rabbitmqctl delete_user guestThen create a separate, scoped user for each application — never point your app at the admin account, and never share one login across multiple services:
sudo rabbitmqctl add_vhost myapp_vhost
sudo rabbitmqctl add_user myapp_worker 'a-different-strong-password'
sudo rabbitmqctl set_permissions -p myapp_vhost myapp_worker ".*" ".*" ".*"A dedicated vhost per app also means one misbehaving service can't accidentally purge or flood another app's queues.
Opening it up for remote workers safely
By default RabbitMQ listens on all interfaces on port 5672 (AMQP) and 15672 (management UI), which is too permissive for a production box. Restrict both at the firewall rather than trying to bind RabbitMQ itself to a single interface, since most setups still need the app server and the queue to talk over a private network:
sudo ufw allow from <app-server-ip> to any port 5672
sudo ufw allow from <your-office-ip> to any port 15672
sudo ufw deny 5672
sudo ufw deny 15672If your app server and RabbitMQ box sit in the same datacenter, use their private network IPs in these rules, not public ones — it's faster and keeps AMQP traffic off the public internet entirely. Never expose 15672 to the world; the management UI is a full admin panel, not a status page.
If you're fronting the management UI with a domain for convenience, put it behind Nginx as a reverse proxy with its own auth layer and a real SSL certificate rather than exposing port 15672 directly.
Common errors and what actually causes them
"ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN"
This is almost always one of three things: the user doesn't have permissions set on the vhost you're connecting to (permissions are per-vhost, not global), the app is connecting to / when the user was only granted access to myapp_vhost, or it's the deleted guest account still hardcoded in a connection string. Check what a user can actually reach with:
sudo rabbitmqctl list_permissions -p myapp_vhost
sudo rabbitmqctl list_user_permissions myapp_workerConnection refused or times out from a remote worker
A refused connection means the firewall actively rejected the packet — check UFW on the VPS. A timeout that just hangs usually means the packet was silently dropped by a network-level firewall in front of the box, like a cloud provider's security group, which is a separate layer from UFW. Confirm what's actually listening first:
sudo ss -tlnp | grep 5672If that only shows 127.0.0.1:5672, RabbitMQ itself isn't the problem — check /etc/rabbitmq/rabbitmq.conf for a stray listeners.tcp override binding it to localhost only.
Queues keep growing and consumers never seem to catch up
Almost always a consumer that isn't acknowledging messages — either autoAck is off and the code never calls ack, or the consumer is crashing mid-message and RabbitMQ is redelivering the same messages in a loop. Check unacked counts in the management UI under the queue's detail page; a large "Unacked" number with a flat "Ack rate" points straight at the consumer code, not RabbitMQ.
Memory or disk alarm blocks all publishing
RabbitMQ deliberately blocks new publishes when it hits its memory or disk-space watermark, rather than crashing or dropping data — this looks like the whole server has frozen, but it's actually working as designed. Check which alarm fired:
sudo rabbitmqctl status | grep -A5 alarmsThe default memory watermark is 40% of total RAM, which is often too aggressive on a small VPS running other services alongside it. Raise it deliberately in /etc/rabbitmq/rabbitmq.conf if the box has room, rather than treating the alarm as the bug itself:
vm_memory_high_watermark.relative = 0.6rabbitmq-server won't start after a config change
rabbitmq.conf uses a strict key-value format, and a stray line or unsupported setting will make it refuse to start rather than ignore the error. Read the actual failure instead of guessing:
sudo journalctl -u rabbitmq-server -n 50 --no-pagerThe log names the exact directive it choked on.
Prevention checklist
- Delete the
guestuser immediately after install — don't rely on its localhost-only restriction. - One vhost and one scoped user per application; never share admin credentials with app code.
- Firewall AMQP (5672) and the management UI (15672) to known IPs only — nothing public-facing.
- Set an alert on unacked message counts, not just queue length, so a stuck consumer gets caught before the queue balloons.
- Give RabbitMQ its own headroom for the memory watermark, especially on a small VPS shared with other services.
Frequently asked questions
Is the default guest/guest RabbitMQ account safe to leave in place?
No. It can only authenticate over localhost by design, but that's not a substitute for real access control. Delete it right after install and create named users with scoped permissions instead.
Can I run RabbitMQ on the same VPS as my web app and database?
Yes, as long as the box has enough RAM for all three. RabbitMQ keeps queue data in memory by default, so watch the memory watermark alarm if you're running it alongside MySQL or a busy PHP-FPM pool.
Why do my messages keep getting redelivered instead of processed once?
This is almost always a consumer that isn't acknowledging messages, either because auto-ack is off and the code never calls ack, or the consumer is crashing mid-message. Check the Unacked count in the management UI to confirm.
Do I need a dedicated vhost for every application?
You don't strictly need one, but it's the cheapest way to stop one app's queues from being purged, flooded, or read by another app's credentials. One vhost and one scoped user per application is the safer default.
Should I expose the RabbitMQ management UI on port 15672 to the internet?
No. It's a full admin panel, not a status dashboard. Restrict it to known IPs at the firewall, or put it behind an authenticated reverse proxy with its own SSL certificate if you need to reach it from outside the office.