Deploy RabbitMQ [Updated Sep'26]

Deploy and Host RabbitMQ on Railway

RabbitMQ is the message broker most background job systems are built on — a self-hosted alternative to Amazon MQ, CloudAMQP and SQS. It routes messages into queues by binding rules and delivers them with per-message acknowledgement, which is what lets a worker crash mid-job without losing it. This template deploys RabbitMQ 4 with the management UI, a volume and a fixed node name, so your queues are still there after a redeploy instead of quietly starting empty.

What This Template Deploys

The management UI takes the public HTTPS domain on 15672. AMQP is raw TCP, so in-project workers connect over the private network on 5672 and external clients need the TCP proxy — two paths that catch most people out.

About Hosting

RabbitMQ is easy to start and easy to lose data on. Every failure below is silent — the broker comes up healthy and reports nothing wrong.

A changing hostname makes the broker forget everything. RabbitMQ derives its node name from the container hostname and stores its Mnesia database in a directory named after it. Railway gives each deploy a new hostname, so the node looks for rabbit@old-host, finds nothing, and initialises a fresh empty database — on the same volume, beside data it can no longer see. Queues, users and vhosts appear to vanish with no error logged. This template pins RABBITMQ_NODENAME so the node finds its own directory every time.

Publishers block at 40% of memory, and it looks like a hang. RabbitMQ applies flow control above its high watermark, which defaults to 40% of available RAM. The producer stops mid-publish with no exception and no timeout — it just waits. On a small container this trips far earlier than expected, and reads like an application deadlock rather than a broker limit. Size RAM for the queue depth you expect, not the binary.

The guest account only works from localhost. RabbitMQ restricts guest to loopback, so a worker on another service gets ACCESS_REFUSED even with the right password. You need a real user, which this template generates as RABBITMQ_DEFAULT_USER and RABBITMQ_DEFAULT_PASS.

A volume alone does not make messages durable. Persistence is two properties: the queue must be durable and the message published as persistent. Get either wrong and the volume faithfully preserves an empty queue across the restart that lost your messages.

The plain image has no management UI. rabbitmq:4 ships without the management plugin, so the -management tag is not cosmetic — without it 15672 serves nothing and you inspect queues only from the CLI.

Typical cost: ~$8–15/month for the broker and a small volume at light traffic, on rates of $10/GB/month RAM, $20/vCPU/month CPU and $0.15/GB/month volumes. Note the interaction with flow control: the cheapest configuration blocks publishers soonest. RabbitMQ is MPL 2.0 and free.

How It Compares

The honest edge: if you need many independent consumers on one stream, or replay from an arbitrary point after a fix, Kafka is the right tool and RabbitMQ will fight you. RabbitMQ wins on everything queue-shaped — task dispatch, dead-letter retries, priority and delayed messages, per-message acks — and on operational weight, since Erlang on half a gigabyte does what a JVM needs several for. Against SQS you trade never patching anything for routing and protocol richness.

Deploy in Under 5 Minutes

1. Click Deploy and pick a workspace. The broker comes up with a fixed RABBITMQ_NODENAME, a volume and generated credentials.
2. Open the public domain and sign in with RABBITMQ_DEFAULT_USER and RABBITMQ_DEFAULT_PASS from the Variables tab.
3. Point your worker at amqp://user:pass@:5672/ over private networking — free, and never leaves Railway.
4. For external clients, enable the TCP proxy under Settings → Networking and use the host and port it generates.
5. Publish one persistent message to a durable queue and watch it appear under Queues in the UI.

> Verify before you rely on it: leave that message unconsumed, redeploy, and check the queue again. If it is still there, the node name and volume are both correct — this is the test that catches the hostname trap.

Common Use Cases

• Background job queues — back Celery, Sidekiq, BullMQ or a custom worker pool, with acks so a crashed worker's job is redelivered rather than lost.
• Retry and dead-letter pipelines — route failures to a dead-letter exchange, retry with backoff, and inspect what's stuck without a bespoke error table.
• Decoupling microservices — publish events instead of calling services directly, so a slow consumer never takes the producer down.

Configuration

> Never change RABBITMQ_NODENAME on a populated volume. The broker looks for a Mnesia directory that does not exist and starts empty, leaving old data on disk but unreachable. Recovery means renaming directories by hand.

> Set credentials in Variables, not the management UI. UI-created users live in Mnesia, while RABBITMQ_DEFAULT_USER only applies to a first-boot empty database — so the two can silently disagree after a volume reset.

Dependencies for RabbitMQ Hosting

• Railway account — ~$8–15/month for the broker and a small volume; more RAM for deep queues.
• Bundled services — none. RabbitMQ runs as a single Erlang node with no external database.
• Volume — required at /var/lib/rabbitmq. Holds durable queues, persistent messages, users and definitions.
• Optional — the TCP proxy for external AMQP clients, shovel or federation for cross-broker links, and a Prometheus scrape of the metrics endpoint.

Deployment Dependencies

• RabbitMQ on GitHub
• RabbitMQ documentation
• RabbitMQ tutorials
• Railway volumes

Implementation Details

The broker runs the official rabbitmq:4-management image on a pinned tag, which bundles the management plugin rather than needing it enabled at runtime. AMQP 0-9-1 and 1.0 listen on 5672, the management UI and HTTP API on 15672, the Prometheus endpoint on 15692. Only the UI port gets a Railway domain; AMQP stays private unless you deliberately enable the TCP proxy, because a broker reachable from the internet is one someone else can publish to.

The setting that matters is the node name. RabbitMQ writes its Mnesia database to a path containing it, and on Railway the container hostname changes every deploy. Pinning RABBITMQ_NODENAME decouples the data directory from the hostname, so the broker reopens the same database instead of creating a new one beside it. RabbitMQ 4 also defaults untyped queues to quorum queues, Raft-based and lighter on memory than the old mirrored ones — worth knowing on a single node, where their replication factor is one.

For backups, the volume holds everything stateful, but export your definitions separately from the UI or HTTP API. Definitions are exchanges, queues, bindings, users and policies as JSON, and restoring them into a fresh broker is far faster than recovering a Mnesia directory. Set queue limits and dead-letter policies deliberately: an unbounded queue with a stalled consumer grows until it hits the memory watermark and blocks every publisher.

Frequently Asked Questions

Why did my queues disappear after a redeploy? Almost always the node name. RabbitMQ keys its data directory by node name, and a changing hostname makes it start a fresh empty database. A fixed RABBITMQ_NODENAME, as this template sets, prevents it.

Why can't my worker connect as guest? RabbitMQ only allows guest from loopback; remote connections get ACCESS_REFUSED regardless of password. Use the generated RABBITMQ_DEFAULT_USER credentials.

My producer stopped without an error. What happened? Most likely flow control. RabbitMQ blocks publishers once memory crosses the high watermark, and the client waits rather than raising. Check the UI for a blocked connection and give the service more RAM.

Is RabbitMQ a replacement for Kafka? For queue-shaped work, yes, and a lighter one. For replayable logs read by many independent consumers, no — RabbitMQ streams only partly close that gap.

Why Deploy RabbitMQ on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying RabbitMQ on Railway you get a job queue broker with the silent failures handled — a fixed node name so redeploys keep your queues, real credentials instead of the loopback-only default, a volume at the right path, and the UI on HTTPS with AMQP kept private.