Queue mode, not default mode
n8n 2.31.4 runs with execution decoupled from the main process. The main container handles the UI and scheduling. A dedicated worker consumes jobs from Redis, and a separate task-runner container isolates code steps.
Work
n8n Queue-Mode Automation Platform
A horizontally scaled n8n deployment: queue mode with dedicated worker and task-runner containers on Postgres 17 and Redis.
Running in production, self-hosted
Why it exists
The problem
The default n8n deployment is one container doing everything: UI, scheduling, and execution. Under real workload a heavy workflow can starve the editor, and a crash takes scheduling down with it. I wanted a platform I could trust with client-facing work. That meant isolating execution from orchestration before it mattered, not after.
If you are hiring me
Your automations get the same setup I trust with my own work. One heavy job cannot take the rest of the system down.
Walkthrough
Watch it run
Architecture
How it is built
Postgres 17 as the system of record
Executions, credentials, and workflow state live in Postgres 17 rather than the default SQLite, which makes concurrent access from the main and worker processes safe.
Redis as the job queue
Redis brokers executions between the main instance and workers, which is what makes horizontal scaling a matter of adding worker containers.
Real workloads
Runs production workflows including a content-gap-analysis pipeline that crawls, compares, and reports on content coverage.
Stack
What it runs on
Related
Where this connects
Service AI automation systems
Reading Zapier vs Make vs n8n compared
Next step
Want a system like this built for you?
Tell me what you are trying to automate. A call is usually enough to scope it.