---
title: "Deploy n8n Queue Mode | Worker, Redis and Postgres, All Pinned"
description: "Main, worker, Redis and Postgres in queue mode. All images pinned."
category: "Automation"
url: https://railway.com/deploy/n8n-queue-mode-or--1
---

# Deploy n8n Queue Mode | Worker, Redis and Postgres, All Pinned

Main, worker, Redis and Postgres in queue mode. All images pinned.

**[Deploy n8n Queue Mode | Worker, Redis and Postgres, All Pinned on Railway](https://railway.com/template/n8n-queue-mode-or--1)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/n8n-queue-mode-or--1/manifest.json

- **Creator:** Templates Guru
- **Category:** Automation

## Template content

### Redis

- **Image:** redis:8.6.5-alpine
- **Start command:** `/bin/sh -c 'redis-server --requirepass "$REDIS_PASSWORD" --appendonly yes --bind 0.0.0.0 :: --protected-mode no'`

### Postgres

- **Image:** ghcr.io/railwayapp-templates/postgres-ssl:18

### n8n

- **Image:** n8nio/n8n:2.36.0
- **Health check:** /healthz
- **Public domain:** Yes

### n8n worker

- **Image:** n8nio/n8n:2.36.0
- **Start command:** `n8n worker --concurrency=10`
- **Health check:** /healthz

## Documentation

# 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.


## Similar templates

- [N8N Main + Worker](https://railway.com/deploy/n8n-main-worker) — Deploy and Host N8N with Inactive worker.
- [Evolution API with n8n](https://railway.com/deploy/evolution-api-with-n8n) — Automate WhatsApp workflows with Evolution API, n8n, and Postgres.
- [Postgres Backup](https://railway.com/deploy/postgres-s3-backups) — Cron-based PostgreSQL backup to bucket storage

Open this page in a browser: https://railway.com/deploy/n8n-queue-mode-or--1