Deploy and Host n8n in Queue Mode on Railway

n8n split across a main instance and a worker, with Redis as the queue and Postgres for state. Every image is pinned, and Redis and Postgres are reachable only over the private network.

About Hosting n8n in Queue Mode

The existing "n8n with workers" template has four problems, and they compound:

No image tags at all. n8nio/n8n and bitnami/redis are written without a version, which means :latest. Two deploys a month apart are not the same software, and a redeploy can change n8n underneath a database it has already migrated.
Bitnami closed its public tag catalogue. That Redis image is no longer a dependable pull, and when it fails it does so quietly.
Redis and Postgres are exposed to the public internet over TCP. A queue backend and a database do not need to be reachable from outside; here they talk over the private network only.
Postgres is on :latest as well.

Roughly one deployment of that template in six fails.

Two more things took finding while building this one:

The n8n image is Alpine, and the private network is IPv6. Without ENABLE_ALPINE_PRIVATE_NETWORKING the app resolves nothing and exits with "Unable to connect to Redis", with no hint that the cause is DNS.
Redis has to bind both stacks. --bind :: alone is not enough, and the default binds loopback, which is reachable from nowhere.

Common Use Cases

Webhook-driven workflows, where the main instance accepts the call and queues the execution for the worker.
More throughput than one process gives, by adding replicas to the worker service while the main instance stays at one.
Workflow state kept in Postgres, which the main instance and the worker both read.

Dependencies for n8n Hosting

Deployment Dependencies

n8n n8nio/n8n:2.36.0, the main instance (public)
n8n worker n8nio/n8n:2.36.0 (private)
Redis redis:8.6.5-alpine, the queue
Postgres ghcr.io/railwayapp-templates/postgres-ssl:18, for state

Implementation Details

The main instance and the worker run the same pinned image, so the code that queues an execution and the code that runs it are the same version.
The worker's health check runs on 5680, not 5679. n8n's own task broker already holds 5679 inside the worker container, and the collision kills the worker on startup.
The worker runs ten executions at a time (--concurrency=10). For more throughput, raise replicas on the worker service; the main instance stays at one.
Binary data stays in the database, because a filesystem volume is not shared between the main instance and the worker. For large files, point n8n at S3 instead.

Verification

Not by a status page. An account was created, a webhook workflow activated, the production URL called, and the execution came back success with mode webhook, which only happens if the main instance queued it to Redis and the worker picked it up.

Why Deploy n8n in Queue Mode 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 n8n in Queue Mode on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.