self hosting

n8n Queue Mode Setup: Redis, Postgres, Workers, and Encryption Key Checklist

Queue mode splits n8n into a main process, Redis-backed queue, database, and worker processes so executions can scale beyond a single process.

Primary query: n8n queue mode setup Intent: deployment checklist Applies to: self-hosted, scaling, queue mode Opportunity: 93 Source-backed draft

Independent third-party notes. n8n is a trademark of its owner and is referenced only for compatibility and troubleshooting context.

Quick Answer

Queue mode splits n8n into a main process, Redis-backed queue, database, and worker processes so executions can scale beyond a single process.

Problem Pattern

The user has outgrown a single n8n process or is considering queue mode, but needs to understand the moving parts before enabling it.

Key Facts

Best scalability: n8n describes queue mode as the best scalability option.
Execution flow: The main process creates execution IDs, Redis holds the queue, workers process executions, and the database stores workflow data and results.
Required mode: Set EXECUTIONS_MODE=queue on the main instance and workers.
Database note: SQLite is not recommended for queue mode; Postgres is recommended.

Recommended Steps

Set a shared N8N_ENCRYPTION_KEY for the main process and all workers.
Set EXECUTIONS_MODE=queue.
Start and configure Redis.
Configure n8n Redis host, port, and optional credentials.
Start one or more worker processes.
Keep all main and worker processes on the same n8n version.

Verification

Workers connect to Redis and the database.
Production executions are processed by workers.
Worker health or readiness endpoints pass if enabled.

Warnings

Queue mode with filesystem binary storage is not supported; use external storage such as S3 when persistent binary data is needed.
Too many workers with very low concurrency can pressure the database connection pool.

Best For

Self-hosted deployments that need to scale execution processing.
Workloads where main UI/API responsibilities should be separated from workers.
Teams already comfortable running Redis, Postgres, and multiple n8n processes.

Not For

Small single-user instances with light execution volume.
Deployments still using SQLite.
Teams without monitoring for workers, Redis, database connections, and failed jobs.

Common Mistakes

Using different N8N_ENCRYPTION_KEY values between main and worker processes.
Forgetting to set EXECUTIONS_MODE=queue consistently.
Running too many workers without considering database connection limits.
Using filesystem binary storage in a queue-mode setup that needs shared binary access.

Examples

Core queue-mode variables All main and worker processes need compatible queue and encryption settings.

EXECUTIONS_MODE=queue
N8N_ENCRYPTION_KEY=use-the-same-secret-everywhere
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
DB_TYPE=postgresdb

Queue-mode topology This is the mental model to use when debugging.

Main n8n process -> creates execution IDs
Redis -> holds execution queue
Workers -> process queued executions
Postgres -> stores workflow data and results

FAQ

Do I need Redis for queue mode?

Yes. Redis is the queue broker that connects the main process and worker processes.

Can I use SQLite with queue mode?

n8n does not recommend SQLite for queue mode. Plan on Postgres for serious queue-mode deployments.

Why do workers fail to decrypt credentials?

A common cause is mismatched N8N_ENCRYPTION_KEY values between the main process and workers.

Sources

n8n Queue Mode Accessed 2026-05-07