Scaling Self-Hosted n8n: Queue Mode and What Breaks First

A single n8n container handles more than most teams expect, but it has a hard ceiling: one Node.js process, one event loop, and no limit on concurrent executions by default. The fix, when you hit that ceiling, is queue mode: a main process, Redis as the execution queue, and a pool of stateless worker processes, all backed by Postgres. This guide covers how queue mode actually works, how to size it with real numbers, which parts are free and which require a paid n8n license, and the five failures that show up first in production.

Why one n8n container eventually stops keeping up

The quickstart everyone runs, docker run n8nio/n8n, is a single process writing to a SQLite file. In this regular mode, every execution runs inside that one process. Three limits follow from that:

• No concurrency ceiling. N8N_CONCURRENCY_PRODUCTION_LIMIT, the setting that caps parallel production executions, defaults to -1, meaning disabled. A traffic burst launches as many simultaneous executions as arrive, and each one competes for the same event loop and memory. Releasing a concurrency slot requires a free turn of the event loop, so under heavy load n8n can temporarily exceed even a configured limit, as the concurrency control documentation notes.
• One slow workflow blocks the rest. A workflow churning through 10,000 JSON rows in a Code node shares the process with every other execution. n8n's memory troubleshooting page lists the symptoms: "Execution stopped at this node", "Connection Lost", 503 errors, and Allocation failed - JavaScript heap out of memory in the server logs.
• SQLite is a production risk. A restart mid-write can corrupt the database file, and there is no clean way to add capacity to a single process. Teams migrating from Zapier often land on this default setup without realising it; the safe Zapier to n8n migration playbook covers the move itself, and this post picks up where that one ends.

To be fair to the single container: n8n's own benchmarking says one instance can handle up to 220 workflow executions per second for a simple Webhook Trigger plus Edit Fields workflow on a 4 GB instance. Most small deployments never need more. Queue mode is about what happens when your workflows are not that simple, or your traffic is not that flat.

How queue mode works

Queue mode splits n8n into three process types, coordinated by Redis:

1. The main process serves the editor UI and API, receives webhook calls, and decides that a workflow should run. Instead of running it, the main process writes the execution ID to Redis.
2. A worker process picks the execution ID off the queue, reads the workflow definition from the shared Postgres database, runs the workflow, writes the results back to the database, and posts a completion message to Redis.
3. The main process picks up that message and informs listeners, for example a webhook caller waiting for a response.

Optionally you add webhook processors: dedicated processes that only receive webhook traffic, so a burst of incoming calls never touches the main process or the editor. A load balancer routes /webhook/* and /webhook-waiting/* paths to the webhook pool and everything else, including /webhook-test/* for manual executions, to the main process. If you run n8n against a wider self-hosted stack, our guide to connecting a self-hosted stack with n8n and webhooks shows what those webhook flows look like end to end.

Every process sets EXECUTIONS_MODE=queue and shares the same N8N_ENCRYPTION_KEY, because any worker may need to decrypt any credential. n8n does not recommend SQLite with queue mode; Postgres is the assumed database. The official queue mode guide is honest about the trade: you gain horizontal scalability, and you pay for it with a little extra latency per execution and a lot more moving parts.

The licensing trap: what is free and what is not

There is real confusion here, partly because n8n's own pricing page lists "Queue mode for scaling" under the paid Business plan. The authoritative answer is on the editions comparison page: queue mode, with Redis and as many workers as you like, is included in the free Community edition. When the pricing page briefly suggested otherwise, an n8n team member confirmed on the community forum that queue mode "is still available as it always has been" and the page was a mistake.

What the paid tiers actually gate, on self-hosted:

• Multi-main mode (more than one main process with automatic leader failover) requires Enterprise.
• External storage for binary data (S3 or Azure) requires Business or Enterprise.
• The workers view in the UI, log streaming, SSO, Git-based version control, environments, and projects are paid features.

The binary data point has a practical consequence most posts miss. In queue mode, n8n does not support filesystem mode for binary data, because workers do not share a disk. The free fallback, per the binary data documentation, is database mode, which pushes file payloads through your primary Postgres. That works, but it adds load to the one component you can least afford to overload. S3 storage solves it cleanly and costs a license. Plan for this if your workflows move large files.

Sizing a queue-mode deployment: a worked example

Take an operations team running about 2 million executions per month, mostly webhook-triggered: order events, support ticket updates, document processing. The numbers:

• Average rate: 2,000,000 / 30 days / 24 h / 60 min is about 46 executions per minute, or 0.77 per second.
• Peak rate: webhook traffic is bursty. Assume a 10x peak during business hours: about 8 executions per second.
• Average execution duration: 3 seconds (API calls, some transformation).
• Concurrent executions at peak: 8 per second x 3 seconds = about 24 executions in flight at once.

Now map that to workers. A worker's --concurrency flag defaults to 10, and n8n recommends setting it to 5 or higher: too many workers each running few parallel jobs can exhaust your Postgres connection pool, which causes processing delays and failures. With concurrency 10:

• 3 workers give 30 execution slots, covering the peak of 24 with modest headroom.
• 4 workers give 40 slots and tolerate one worker dying during the peak.
• 2 webhook processors behind a load balancer absorb the incoming request burst.
• 1 main process, 1 Redis, 1 Postgres.

This mirrors the shape of n8n's own multi-instance benchmark, which used two webhook instances, four workers, one database, and one main with Redis. Start there and adjust with measurements, not guesses.

Two memory checks before you call it done:

• Worker RAM. Memory per worker is roughly your heaviest workflow's peak data size times its concurrency. If a workflow loads 200 MB of JSON and a worker runs 10 of them at once, that worker needs over 2 GB free. n8n's guidance for memory-heavy workflows is to chunk data (200 rows per execution instead of 10,000), avoid the Code node where possible, and split workflows into sub-workflows that return limited data to the parent.
• Redis RAM. Webhook responses travel back through Redis as queue messages. The relay limit N8N_WEBHOOK_RESPONSE_RELAY_SIZE_MAX defaults to 64 MiB, and n8n advises budgeting about 1.5x that per large response in flight. Twenty simultaneous 64 MiB responses means roughly 2 GB of Redis memory. If your workflows return big payloads, enable response offloading to binary storage (available from n8n 2.34.0) or cap the limit lower.

Setting it up: the checklist

Here is the minimum sequence, assuming Docker Compose:

1. Move to Postgres first. Run regular mode against Postgres before adding queue mode. One change at a time makes failures diagnosable.
2. Set the shared secrets. N8N_ENCRYPTION_KEY, Postgres credentials, and Redis credentials must be identical on every process. Store the encryption key somewhere off the host: every credential in the database is encrypted with it, and losing it makes restored backups useless.
3. Add Redis. A small instance is enough for most loads; give it a password even on a private network.
4. Start workers. Each is the same image with a different command:

docker run -e "EXECUTIONS_MODE=queue" n8nio/n8n worker --concurrency=10

5. Add webhook processors when webhook traffic is the bottleneck, and configure the load balancer to route /webhook/* and /webhook-waiting/* to them. Set N8N_WEBHOOK_URL (from n8n 2.30.0; WEBHOOK_URL on older versions) so generated webhook URLs point at the public address.
6. Optionally remove the main process from webhook serving with N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true, keeping it dedicated to the UI, API, and queue coordination.
7. Turn on health checks with QUEUE_HEALTH_CHECK_ACTIVE=true so your orchestrator can restart stuck workers.
8. Pin the n8n version on every process. All mains and workers must run the same version, and a floating latest tag guarantees they eventually will not.

Two Compose-specific traps from the Redsf production stack, a good reference deployment: the worker service must not have a container_name (it caps you at one replica, and scaling silently fails), and scale workers with replicas rather than new machines until you outgrow one host:

docker compose up -d --scale n8n-worker=4

What breaks first (and how to see it coming)

In rough order of appearance:

• The database. It is the shared state for every process: workflow definitions, execution records, credentials, and (in database binary mode) file payloads. Many workers at low concurrency exhaust the connection pool; saved successful executions bloat storage until queries slow. Both hit Postgres first.
• Execution history. Every execution writes data by default. Pruning is on by default, deleting executions older than 336 hours (14 days) or beyond 10,000 total, per the execution data documentation. For real volume, go further: EXECUTIONS_DATA_SAVE_ON_SUCCESS=none keeps only error executions, which are the ones you debug from. Annotated executions are never pruned, and running or waiting ones are skipped.
• Worker memory. The first OOM usually comes from a Code node processing a large API response, or a manual execution of a big workflow (manual runs copy data for the frontend). The fix is workflow design, not just bigger containers.
• Redis memory on large webhook responses. Covered in the sizing section; the symptom is "The response is too large to be sent back from the worker" errors.
• Credential decryption errors after a restore. Not a scaling failure, but the one with no recovery: a backup restored without the matching N8N_ENCRYPTION_KEY contains credentials nothing can decrypt.

When queue mode is the wrong choice

Queue mode is infrastructure, and infrastructure has an operating cost: Redis and Postgres to patch and back up, health checks to wire, versions to keep in lockstep. Skip it when:

• Your volume is modest. Under a few hundred thousand executions a month with workflows that finish in seconds, one 4 to 8 GB instance with N8N_CONCURRENCY_PRODUCTION_LIMIT=20 set is simpler and sufficient. The concurrency limit alone fixes the "burst kills the box" failure for most teams.
• You are still on SQLite. Migrate to Postgres and measure before adding more components.
• Your workflows move large files and you want to stay on the free edition. Database-mode binary storage will push those files through Postgres. Redesigning the workflows to pass file references instead of payloads, or paying for external S3 storage, beats pretending the problem is not there.
• Nobody will own the stack. If there is no engineer who will patch Redis, test restores, and watch the queue, n8n Cloud or a managed deployment is cheaper than the incident you are scheduling. If you are still choosing platforms, our n8n vs Zapier vs Make comparison lays out the trade-offs.

Common mistakes

• Scaling workers before constraining executions. Set the concurrency limit in regular mode first; you may never need queue mode.
• Low concurrency with many workers. It feels safer and it exhausts the Postgres connection pool. Use concurrency 5 to 10 per worker and scale worker count, per n8n's recommendation.
• Putting the main process in the webhook load balancer pool. Manual test executions (/webhook-test/*) break, and the editor competes with traffic bursts.
• Storing successful execution data. The fastest route to a database nobody can back up. Save errors only.
• Running latest. One docker compose pull and your workers are a different version from your main, which queue mode does not tolerate.
• Giving the worker service a container_name. Compose refuses to scale it past one replica, and the error message will not tell you why.
• Keeping the encryption key only on the host. See the unrecoverable failure above.

What it costs

Three honest options:

• Self-hosted Community edition: $0 in license fees, infrastructure only. A single 8 GB general-purpose droplet at DigitalOcean runs $63 per month and can host main, workers, Redis, and Postgres for the worked example above; a split setup with a 16 GB database host and a second app host runs about $190 per month at published droplet prices. Add your engineering time, which is the real line item.
• n8n Cloud: Starter at $20 per month billed annually includes 2,500 executions and 5 concurrent; Pro starts at $50 per month for 10,000 executions and up to 50 concurrent, on the n8n pricing page. Above that you are looking at higher Pro tiers or Enterprise.
• Self-hosted Business at $800 per month: worth it when you need SSO, Git version control, environments, or external binary storage, not for queue mode, which is free.

For many organisations the deciding factor is not the licence but who operates the database, the backups, and the 2 a.m. alert. If you would rather outsource that layer entirely, a managed open-source stack arrangement covers exactly those components.

Frequently asked questions

Is n8n queue mode free? Yes. Queue mode with Redis and unlimited workers runs on the free Community edition. What requires a paid license is multi-main high availability (Enterprise), external S3 or Azure storage for binary data (Business or Enterprise), and the workers view in the UI.

How many executions can one n8n instance handle? n8n's published benchmark measured up to 220 workflow executions per second on a single 4 GB instance running a simple webhook workflow. Real numbers depend entirely on your workflows: heavy API calls, large JSON payloads, and Code nodes cut that figure sharply. Benchmark your own workflows before sizing.

Can I use queue mode with SQLite? n8n does not recommend it. Queue mode assumes Postgres, and SQLite on a container volume adds corruption risk on restarts. Move to Postgres first; it is a prerequisite, not an optimisation.

Why are my executions stuck in the queue? Almost always one of three causes: no worker process is running, the workers cannot authenticate to Redis, or the main process and workers disagree on configuration. Check worker logs first, then Redis connectivity, then that EXECUTIONS_MODE=queue and the shared encryption key are set identically everywhere.

Do I need Kubernetes to run n8n in queue mode? No. Docker Compose with service replicas handles main, workers, Redis, and Postgres comfortably into the millions of executions per month. Kubernetes helps when you need multi-host scheduling and rolling upgrades, and it adds operational weight long before it adds value.

What is the difference between the main process, a worker, and a webhook processor? The main process runs the editor, the API, and queue coordination. Workers execute workflows pulled from Redis. Webhook processors are dedicated receivers for incoming webhook traffic, sitting behind a load balancer so request bursts never touch the main process or the editor.

Where to go from here

Queue mode is a solved problem once you respect the shared database, size workers with real numbers, and save error executions only. If you want the automation without becoming the on-call engineer for Redis and Postgres, our business automation service designs, deploys, and runs n8n-based workflows for operations teams, including the queue-mode setup described here.