---
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-worker-redis-and-postg
---

# 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-worker-redis-and-postg)**

- **Creator:** Pavel Volkov's Projects
- **Category:** Automation
- **Total deploys:** 2

## Template content

### n8n worker

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

### Postgres

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

### n8n

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

### 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'`

## Documentation

# n8n in queue mode

n8n split across a main instance and a worker, with Redis as the queue and
Postgres for state. Everything pinned.

## What this fixes

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 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 through public TCP proxies.** A queue backend
  and a database do not need to be reachable from the internet; here they talk
  over the private network only.
- Postgres is on `:latest` as well.

Roughly one deployment in six fails.

## What this runs

`n8nio/n8n:2.32.5` for both the main instance and the worker, `redis:8.6.5-alpine`,
and `postgres-ssl:18` — every one pinned.

## Two things that took finding

- **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 leaving
  the default binds loopback, which is reachable from nowhere.

The worker's health check also runs on 5680, not 5679: n8n's own task broker
already holds 5679 inside the worker container, and the collision kills it on
startup.

## Verified

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.

## Scaling

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 main and worker. For large files, point n8n at S3 instead.


## 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) — [Jul'26] WhatsApp automation platform using Evolution API, n8n & PostgreSQL
- [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-worker-redis-and-postg