In its default "main" mode, n8n runs everything in one process — triggers, executions, and the editor together. That is fine for modest load, but it caps throughput and makes a heavy workflow able to starve everything else. Scaling n8n is mostly one architectural move — queue mode — plus knowing which resource is actually limiting you.
Switch to queue mode
Queue mode splits n8n into a main process that handles triggers and the UI, a Redis queue that holds pending executions, and a pool of worker processes that pull from the queue and run workflows. Now executions run in parallel across workers, a slow workflow no longer blocks the others, and you scale throughput by adding workers rather than by making one process bigger.
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
# Run the main instance, then scale workers independently:
# n8n worker (× N — add workers to add throughput)Find the real limit first
Do not add workers blindly — identify what is actually constraining you:
- External APIs — if workflows spend their time waiting on third-party calls, the limit is the downstream rate limit, not n8n; more workers just hit it harder.
- Database — n8n stores execution data in its database; heavy execution volume with full data saving can make the DB the bottleneck. Prune execution history and consider what you persist.
- Workers — if workflows are CPU or logic heavy and the queue is backing up, that is when more workers genuinely help.
Tune concurrency and retention
Each worker runs multiple executions concurrently; set that concurrency to match the work (higher for I/O-bound, lower for CPU-bound). And control execution-data retention — saving full data for every execution forever bloats the database and slows everything. Prune old executions and save less detail for successful runs to keep the database healthy as volume grows.
The honest signal for adding workers is a queue that is consistently growing — executions arriving faster than they drain. If the queue stays shallow, more workers do nothing but consume resources. Scale to the queue depth, not to a hunch.
Scale n8n by moving to queue mode with Redis and independent workers, but diagnose the bottleneck first — often it is an external API or the database, not n8n's compute. Tune worker concurrency to the workload, prune execution data, and let a growing queue, not guesswork, tell you when to add capacity.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.