Scaling with queue mode

By default one n8n process does everything: shows the editor, receives webhooks, and runs every execution. Under heavy load (many webhooks, long AI runs) it becomes the bottleneck. Queue mode splits the work.

The parts:

• Main instance: serves the editor and API, handles schedules and incoming webhooks, and creates executions. It does not run them; it puts their IDs in a queue.
• Redis: a fast in-memory data store used as the message broker, the waiting line of executions.
• Workers: separate n8n processes started with n8n worker. Each takes executions from Redis, loads the workflow from the database, runs it and saves the result. Add more workers to handle more load.
• PostgreSQL: one shared database for all of them. SQLite isn't supported here.
• Optional webhook processors (n8n webhook) behind a load balancer (a server that spreads incoming requests) for very high webhook traffic.

Configuration essentials:

• Set EXECUTIONS_MODE=queue and the Redis connection settings on every process.
• Every worker and webhook processor must use the same N8N_ENCRYPTION_KEY as the main instance, or they can't read credentials.
• Worker concurrency (parallel executions per worker) defaults to 10; n8n advises at least 5, since many low-concurrency workers can exhaust database connections.
• Binary data (files) can't live on one machine's disk; use S3-compatible storage (a cloud file store).

Enterprise self-hosted plans add multi-main setups for high availability.

Measure first: execution data pruning and lighter workflows often fix slowness before scaling is needed.