Scaling n8n
n8n scales perfectly well. One container running everything, and fifty workflows nobody owns, do not.
Three walls, in the order you hit them
Almost nobody outgrows the n8n engine. They hit one of these, long before the engine is the limit.
Wall one: everything in one process
By default n8n runs the editor, the webhooks and the executions in a single process. Under load a heavy workflow starves everything else, and a restart drops whatever was mid-run.
The fix is queue mode. The main instance accepts the work and pushes it to Redis; separate worker processes do the running. More volume, more workers. Webhook handling can be split out too.
Pair that with Postgres, never the built-in file database in production, sized and maintained properly, and delete old execution history on a schedule so the database does not become the next thing that is slow. This is the architecture we deploy for larger customers.
Wall two: how the workflows are built
No amount of hardware rescues a badly shaped workflow.
- Send things in batches, rather than one API call per item in a loop, and respect the rate limits of whatever you are calling.
- Break up the monsters. A workflow with 120 nodes cannot be understood or tested. Compose smaller workflows that call each other.
- Make every step safe to run twice. This is the difference between "it recovered" and "it paid the invoice twice".
- Give every workflow a failure path that tells a human. A global error handler that alerts a channel is the minimum (what good ones look like).
Wall three: nobody owns them
Fifty workflows later: nobody knows which are load-bearing, three do the same job in different ways, and one nobody remembers building touches production billing.
Scaling the operation means an owner for each workflow, names that mean something, changes moving through environments instead of being made live, and monitoring that tells someone when a run fails rather than adding it to a list nobody opens.
This wall is people-shaped, and it is the one that actually kills automation programmes. No tool fixes it. Ownership does, whether that is in-house or somebody you pay to own it.
When it is not a volume problem at all
Some scaling problems are really capability problems. Volume grows because messy cases, the email in the wrong format, the exception, the thing that needs a decision, are being forced down rigid branches, and every new exception adds another branch.
More workers will not fix that. Putting an AI employee in front of the workflow will: it absorbs the mess and hands the workflow a clean, predictable job, which is what workflows are good at. At larger scale that becomes a team of agents calling workflows as tools.
If you are hitting one now
Walls one and two are an engineering sprint. Wall three is an operating model. We handle all three for customers, on whichever infrastructure they choose. Or just tell us what is slow and we will tell you which wall you are on, free.
FAQ
How do I know if I have outgrown n8n?
You almost certainly have not. Teams who think they have are usually hitting one of three fixable walls: everything running in one process, workflows built in a way that cannot cope with volume, or nobody owning the fifty workflows they now have.
What is queue mode?
By default n8n does everything in one process, so a heavy workflow starves the rest and a restart drops work in progress. In queue mode the main instance accepts jobs and hands them to separate worker processes through Redis. More volume, more workers.
What database should I use?
Postgres, never the built-in file database in production. Size it properly, maintain it, and delete old execution history on a schedule so the database does not become the next bottleneck.
How do I stop retries causing damage?
Design each step so running it twice is harmless. That is the difference between a workflow that recovered and a workflow that invoiced the customer twice. Add an error path that alerts a person, on every workflow.
What is workflow sprawl?
Fifty workflows in, nobody knows which ones matter, three do the same job in different ways, and one that nobody remembers building touches billing. It is the wall that actually kills automation programmes, and it is a people problem, not a technical one.