Running automations for multiple clients: the four isolation patterns
19 August 2026 · 6 min read
Every agency doing automation work arrives at the same architectural fork, usually around client four or five, usually after something went wrong. Here are the four patterns people actually use and where each one stops working.
1. One shared instance, workflows tagged by client
Cheapest and fastest to start. One server, one upgrade, one thing to monitor. It is also the pattern with the largest blast radius: a bad deploy, a rate limit, or a runaway loop touches every client at once, and one client's credentials sit in the same store as everyone else's.
Works fine at two or three clients. The failure mode is not gradual — it is one bad afternoon.
2. One instance per client
Proper isolation: separate credentials, separate failure domain, straightforward to hand over if a client leaves. This is what most agencies move to once burned.
The cost is operational, not financial. Every instance is another thing to update, monitor, back up and log into. A practitioner in r/n8n put the scaling worry plainly:
“After a while the more client instances the more overhead?”
r/n8n, Jul 2026
And the tracking problem shows up in the same threads:
“We've got 7 client instances and i'd rather not add an 8th line to that notepad.”
r/n8n, Jul 2026
3. Client-owned accounts
The client pays for and owns the instance; you build inside it. Clean commercially — it sidesteps the licensing question entirely — and the client keeps what they paid for.
The cost is access sprawl. Every client is a separate login, a separate billing relationship you do not control, and a separate place their API keys live. You also lose the ability to see across all your work at once, which is exactly what you need most as client count grows.
4. A platform built for it
Isolation per client, one place to see every run, one credential store with proper scoping, and billing that maps to clients rather than servers. This is the category we are building in, so treat the recommendation accordingly.
The question that actually decides it
Not 'which is best' — it is 'what happens when a workflow stops firing and nobody notices for two days?' Pattern 1 means it happened to everyone. Pattern 2 means you find out when you next log into that specific instance. Pattern 3 means you may not find out at all.
Whichever pattern you pick, the thing worth building first is not the isolation. It is the ability to see, in one place, that everything ran.
Tenvik
The ops layer for agencies running n8n for clients. No product yet — the founding list decides whether it gets built.
Join the founding list