n8n Queue Mode Checklist: Redis, Postgres 16+, Workers

The symptom that sends most teams here is not a single error message. It is a scaling pattern:

• the main n8n process becomes the bottleneck
• webhook latency grows under load
• one busy workflow blocks unrelated work
• you need more throughput without cloning the whole instance blindly

The root cause is that default single-instance execution stops being enough. Queue mode is n8n's documented scale-out model.

What queue mode actually does#

The n8n docs describe the flow like this:

1. the main instance receives the trigger or webhook
2. it passes the execution ID to Redis
3. a worker picks the job up
4. the worker reads workflow data from the database and executes it

That architecture is why queue mode scales better than just making one big main process.

The four requirements teams usually miss#

1. Use Postgres, not SQLite#

n8n's queue-mode docs state that running n8n with execution mode set to queue with an SQLite database isn't recommended. For the database itself, n8n's supported-databases page lists PostgreSQL 17 and 18, plus 16 for compatibility, so plan on Postgres 16+.

If your self-hosted instance still uses SQLite, treat queue mode as a migration project, not just an environment-variable tweak.

2. Share the same encryption key#

The docs are very clear here: the main instance's encryption key must be shared with all worker and webhook processor nodes so they can access credentials stored in the database.

If you skip this, workers may be alive but unable to use credentials correctly.

3. Run Redis and point n8n at it#

Queue mode depends on Redis as the message broker.

At minimum, the docs show these environment variables for the main process:

EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=localhost
QUEUE_BULL_REDIS_PORT=6379

If your Redis instance has auth or a non-default DB, you can also configure:

QUEUE_BULL_REDIS_USERNAME=...
QUEUE_BULL_REDIS_PASSWORD=...
QUEUE_BULL_REDIS_DB=0

4. Start actual worker processes#

Setting EXECUTIONS_MODE=queue is not enough by itself. The docs explicitly say you need worker processes so n8n can execute workflows.

That is the part people miss when they flip the env var and see no improvement.

The binary-data caveat that breaks migrations#

The queue-mode docs also call out an important restriction: n8n does not support queue mode with binary data stored in the filesystem.

If your workflows persist binary files, you need external storage such as S3 instead of assuming the local filesystem setup will keep working unchanged.

Minimal deployment checklist#

Use this as the first pass:

1. Migrate to Postgres if you are still on SQLite
2. Set and share the same encryption key across main and workers
3. Start Redis
4. Set EXECUTIONS_MODE=queue on the main instance and workers
5. Configure QUEUE_BULL_REDIS_HOST and QUEUE_BULL_REDIS_PORT
6. Start one or more worker processes
7. Move binary persistence off the filesystem if your workflows depend on it

What happens to webhooks in queue mode#

Queue mode does not remove webhook handling from the front door. The docs say the main or webhook process still receives the HTTP request, then hands execution off to a worker.

That means queue mode improves throughput, but it can also add some overhead and latency to the handoff. It is the right tradeoff when reliability and scaling matter more than doing everything in one process.

A realistic starting env file#

N8N_ENCRYPTION_KEY=replace-with-your-shared-key
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379

Then make sure both the main instance and every worker use the same database, the same Redis, and the same encryption key.

When queue mode is the wrong next step#

If you are still debugging basic workflow logic, flaky credentials, or webhook registration, fix those first. Queue mode is a scaling tool, not a cure for broken workflow design.

These are the best companions if you are building a more production-ready n8n stack:

• n8n Complete Beginner Guide 2026: Build Your First Automation Workflow
• How I Fixed My n8n Workflow That Was Failing Silently for Three Weeks
• n8n Lead Capture to Notion: Webhooks, Scoring, Slack Alerts
• n8n Client Reporting Workflow: ClickUp, Toggl and Gmail

References#

• n8n docs: Queue mode
• n8n docs: Queue mode environment variables

What happens when a worker dies mid-execution#

The checklist above gets queue mode running, but the first production question teams hit is: what happens to a workflow if the worker executing it crashes, gets OOM-killed, or the container is redeployed halfway through a run?

n8n's queue mode is built on the Bull queue library, which tracks job ownership through a lock that the active worker has to keep renewing while it processes a job. The queue-mode environment variables expose the timings: QUEUE_WORKER_LOCK_DURATION (default 60000 ms) is the lease period, QUEUE_WORKER_LOCK_RENEW_TIME (default 10000 ms) is how often the worker renews it, and QUEUE_WORKER_STALLED_INTERVAL (default 30000 ms) is how often a worker checks for stalled jobs. If a worker dies, it stops renewing the lock, and once the lease runs out Bull treats the job as stalled.

What happens next is set in n8n's own code, not by Bull's defaults. n8n's scaling.service.ts builds the queue settings as { ...this.globalConfig.queue.bull.settings, maxStalledCount: 0 }. With maxStalledCount at 0, a stalled job is not handed to another worker: it fails. The docs list QUEUE_WORKER_MAX_STALLED_COUNT as "Deprecated. Removed in n8n 2.0. Setting this has no effect", so there is no environment variable that turns automatic re-runs back on.

Three practical consequences follow from this:

1. Nothing resumes the execution for you. A workflow that was running on a worker that crashed, got OOM-killed or was redeployed mid-run stops where it was. Find it in the executions list and re-run it yourself once the worker problem is fixed.
2. Make side-effect nodes idempotent. A manual re-run can repeat work that already happened before the crash: an email already sent, a card already charged, a row already inserted. Give each external call a dedupe key, or protect inserts with a unique constraint, so a second attempt is harmless.
3. Treat repeated stalled failures as a worker-stability problem. They point at memory limits, container restarts or deploy timing, not at the workflow logic or its trigger.

Further reading: n8n requested webhook is not registered fix. Also see n8n Microsoft OAuth2: Fix 'Need Admin Approval'.