---
title: "Deploy RabbitMQ [Updated Sep'26]"
description: "Self-host RabbitMQ — AMQP broker for Celery, Sidekiq, BullMQ workers"
category: "Queues"
url: https://railway.com/deploy/rabbitmq-background-jobs
---

# Deploy RabbitMQ [Updated Sep'26]

Self-host RabbitMQ — AMQP broker for Celery, Sidekiq, BullMQ workers

**[Deploy RabbitMQ [Updated Sep'26] on Railway](https://railway.com/template/rabbitmq-background-jobs)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/rabbitmq-background-jobs/manifest.json

- **Creator:** SB
- **Category:** Queues

## Template content

### RabbitMQ https://avatars.githubusercontent.com/u/96669?s=200&v=4

- **Image:** rabbitmq:4-management
- **Public domain:** Yes

## Documentation

# 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

| Service | Purpose |
| --- | --- |
| `rabbitmq` | Broker on AMQP `5672`, management UI on `15672`. Official `rabbitmq:4-management`. |
| Volume | Mounted at `/var/lib/rabbitmq` — durable queues, users, vhosts, definitions. |

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

| | RabbitMQ (self-hosted) | Kafka | Amazon SQS | CloudAMQP |
| --- | --- | --- | --- | --- |
| Message model | Queue, consume once | Replayable log | Queue, consume once | Queue, consume once |
| Cost model | Flat infra | Flat infra | Per request | Per plan tier |
| Self-hostable | Yes | Yes | No | No |

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

| Variable | Required | Description |
| --- | --- | --- |
| `RABBITMQ_NODENAME` | Pre-set | Fixed node name. Keeps the Mnesia directory stable across redeploys. |
| `RABBITMQ_DEFAULT_USER` | Generated | Broker admin and AMQP login. Replaces the loopback-only `guest`. |
| `RABBITMQ_DEFAULT_PASS` | Generated | Password for the above. Rotate in Variables, not the UI. |
| `RABBITMQ_VM_MEMORY_HIGH_WATERMARK` | Optional | RAM fraction before publishers block. Default `0.4`. |
| Storage volume | Pre-set | Persistent volume at `/var/lib/rabbitmq`. |

> **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](https://github.com/rabbitmq/rabbitmq-server)
- [RabbitMQ documentation](https://www.rabbitmq.com/docs)
- [RabbitMQ tutorials](https://www.rabbitmq.com/tutorials)
- [Railway volumes](https://docs.railway.com/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.

## Similar templates

- [smoothmq](https://railway.com/deploy/AJv-64) — A drop-in replacement for AWS SQS
- [Kafka UI](https://railway.com/deploy/kafka-ui) — Kafbat UI — Open-source web UI to monitor and manage Apache Kafka clusters
- [Hatchet Lite](https://railway.com/deploy/hatchet-lite) — Hatchet Lite with postgres

Open this page in a browser: https://railway.com/deploy/rabbitmq-background-jobs