Deploy n8n Queue Mode | Worker, Redis and Postgres, All Pinned
Main, worker, Redis and Postgres in queue mode. All images pinned.
n8n worker
Just deployed
Just deployed
/var/lib/postgresql/data
Just deployed
/home/node/.n8n
Redis
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/n8nandbitnami/redisare 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
:latestas 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_NETWORKINGthe 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
n8n worker
n8nio/n8n:2.32.5Redis
redis:8.6.5-alpine