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

Just deployed

/var/lib/postgresql/data

Just deployed

/home/node/.n8n

Just deployed

/data

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.


Template Content

More templates in this category

View Template
N8N Main + Worker
Deploy and Host N8N with Inactive worker.

jakemerson
119
View Template
Evolution API with n8n
Automate WhatsApp workflows with Evolution API, n8n, and Postgres.

codestorm
84
View Template
Postgres Backup
Cron-based PostgreSQL backup to bucket storage

Railway Templates
871