How much isolation does a client book actually need?
Four working positions, not a ladder. The right one depends on what the workflows touch — this is a consequence question, not an architecture-purity one.
| Model | What it isolates | What it does not | Operational cost |
|---|---|---|---|
| Shared instance, naming conventions Folders, tags, prefixes |
Nothing technically. Human navigation and convention only | Credentials, execution, logs, cost. Any workflow can reference any connection; one loop degrades everyone | Lowest — one thing to run, patch and back up |
| Shared instance, projects or workspaces n8n projects, Zapier Workspaces, Workato environments and projects |
Workflows and the credentials they use, with per-project roles and membership | The runtime. One process, one queue, one upgrade, one execution log to disentangle at offboarding | Moderate — roles and membership to maintain, plan-tiered pricing |
| Container or instance per client From one shared stack |
Credentials, execution, data and logs. Own container, own database schema | The host, and anything shared beneath it — an encryption key, a floating image tag, a database server | High — n things to run, monitor, patch and upgrade |
| Fully separate deployments Separate infrastructure or vendor accounts |
The host and the platform account as well, so a compromise is bounded by client | Upstream vendor risk. A platform closing still closes for all of them at once | Highest — usually justified by a contract or a regulator, not by preference |
The case for the third position is made well in a practitioner thread on n8n's own community forum — an operator account rather than vendor documentation, which is what makes it useful. Each client's credentials, they write, meaning Salesforce, HubSpot and Gmail tokens, "live in their own container and their own database schema. No risk of cross-tenant leaks." On blast radius: "If one client's n8n misbehaves, it doesn't take down the others." On offboarding: tear down one container.
Be fair to the second position, though, because it is where most agencies should probably sit. A shared instance with genuine project scoping is a legitimate choice for low-risk work. A consultancy write-up on multi-tenant automation puts the condition plainly: the shared-instance trade-off requires "discipline in workflow authoring, rigorous testing, and automated checks to prevent any cross-tenant leaks." That is a real cost, paid in review process rather than infrastructure — but for newsletter automation and CRM hygiene it is a rational place to pay it.
Why are credentials the real boundary?
Because a workflow definition is inert and a credential is capability. Separating workflows into per-client projects while every one of them can still reach a shared connection pool gives you a tidier interface and exactly the same tenancy boundary you had before.
This is why n8n's projects scope workflows and credentials together, with per-project roles. It comes with a caveat worth knowing before you reorganise anything: n8n's documentation states that credentials must move with workflows across projects, or executions break. That is the boundary doing its job. A workflow that kept running after you moved it away from its credentials would be the thing to worry about.
The practitioner pattern goes one level further down. A per-client database schema is what actually delivers "no risk of cross-tenant leaks", because the separation is then enforced by the storage layer rather than by application logic a mistake could talk its way around. The counterpart failure is secrets sprawling into version control, which the same consultancy write-up flags — and if a client's API key is recoverable from your repository history, the container boundary above it is decorative. What an automated actor should be allowed to hold in the first place is covered in what permissions an AI agent should hold.
The hosted platforms attack the same problem with their own primitives, and they are substantial rather than cosmetic.
| Platform | Tenancy primitives | Where it runs |
|---|---|---|
| n8n | Projects scoping workflows and credentials together, with per-project roles. All Cloud plans; self-hosted on Registered Community, Business and Enterprise | Self-hostable, so a per-client container is available to you |
| Zapier | Workspaces, Managed App Connections, Action Restrictions, app allowlist and blocklist, Domain Restrictions, role-based access, audit logs, Asset History as a queryable execution audit trail, log streaming to Datadog and Splunk | Cloud-only. Zapier staff state on the official community that "Zapier is a cloud-based application and is not available on-premises" |
| Workato | Environment roles and project roles, custom roles, activity audit log with external streaming, dev/test/prod separation, AES-256 with double-encrypted job history | Cloud-only. The On-Prem Agent is a connectivity bridge, not an on-premises deployment — orchestration and processing stay in Workato's cloud. Residency US and EU (Frankfurt) |
| Make | RBAC; SOC 2 Type II, SOC 3 and ISO 27001 at Enterprise | Cloud, with Enterprise in an isolated AWS environment |
If a client contract puts processing inside your own boundary, that requirement decides the model before any tenancy feature does.
What does your credential encryption actually depend on?
This is the single most expensive mistake available in this architecture, which is why it gets its own section. From the same practitioner thread:
"The N8N_ENCRYPTION_KEY must be consistent and backed up. If it changes, every client's stored credentials become unrecoverable."
Read that as a general property rather than an n8n quirk. In a single-tenant setup, losing the key means reconnecting your own integrations — annoying. In a client book it means going back to every client and asking them to re-authorise systems you do not own, all at once, and explaining why. Whatever platform you are on, find out what the credential encryption depends on, and back that dependency up separately from the instance it protects. A backup of the container that also contains the key is the lock and the key in the same box.
Why does running :latest cost you later?
The second warning from the same source:
"Pin your n8n version. Running :latest means clients created at different times can end up on different versions, and an update can break workflows with no warning."
This is the tax on per-client isolation, stated precisely. Onboard one client in March and another in September against a floating tag and you are operating two estates rather than one, with no record of which client sits where. The failure presents as a workflow that worked yesterday, on one client only, after a redeploy nobody logged. The answer is unexciting: pin versions explicitly, keep a register of which client runs which, and treat upgrades as a staged path — one client first, watched, then the rest — rather than an ambient property of your image tag.
Can you say what each client's automation costs you?
Usually not, and the consultancy write-up above calls billing attribution "a frequent pain point" for exactly that reason: without instrumentation, agencies cannot allocate cost per client. The practical consequence is that you either absorb the cost or estimate it, and estimates drift in the direction of the heaviest client subsidised by the lightest.
The useful observation is that this is the same instrumentation problem as the audit trail. Attribution needs per-operation metadata — which client, which workflow, which run, what it consumed. So does evidence. You are recording the same records either way, so build it once and read it twice: as an invoice line and as a defensible record of what ran. See how to build an audit trail for AI agents for what that record needs to contain. There is an early-warning benefit too — a misconfigured retry loop shows up as a cost anomaly on one tenant days before anyone reports a failure.
Would your offboarding survive a client asking for it tomorrow?
Offboarding is a design requirement, not an afterthought, and it is the only test of the isolation model that returns an unambiguous result. The test has three parts, and each one has to be demonstrable rather than assertable. Can you hand the client their workflows in a form they can run somewhere else? Can you delete their data, including execution history? Can you revoke every credential in every connected system — and prove that you did?
Relay.app's customers are discovering the cost of not asking those questions in advance. Paid accounts close at 23:59 PT on 14 September 2026, and the workspace and credentials are deleted; the team was acquihired by Google. The export does not contain execution history, and credentials are simply removed. A single team on Relay has one migration. An agency with twenty clients on Relay has twenty, all due on a date somebody else set. We covered the specifics in what to do with the time left, and the procurement questions that follow in workflow portability.
Worth reading alongside Forrester's 2026 automation predictions, which hold that "less than 15% of firms will turn on the agentic features in intelligent automation suites," attributed to governance and ROI concerns. For an agency the governance question is sharper than for anyone else, because the actions would be taken on someone else's data, under someone else's contract, with credentials you were lent.
Frequently asked questions
Should each client get their own instance?
It depends on what a mistake costs. Per-client containers give the cleanest credential boundary and single-command offboarding, and multiply patching and upgrade work by client count. A shared instance with per-client projects is a legitimate choice for low-risk work.
Does isolating workflows isolate credentials?
Not by itself. Per-client folders that can all reach the same connections give navigation, not isolation. n8n's projects scope both together with per-project roles; note that credentials must move with workflows across projects or executions break.
What happens if the encryption key changes?
Every stored credential becomes unrecoverable, for every client at once. Back the key up separately from the instances it protects, and find the equivalent dependency on whatever platform you use.
How do I allocate cost per client?
Only by instrumenting for it. It is the same per-operation metadata the audit trail needs, so record it once and use it for both attribution and evidence.
What should offboarding involve?
Handing over runnable workflows, deleting the client's data and execution history, and revoking every credential — each of them provable. If any step means picking records out of a shared structure by hand, the isolation was notional.
Where this leaves you
The honest trade-off is that isolation costs money and operational overhead, and buying more of it than the work requires is its own kind of mistake. A marketing-automation workflow and a payment-approval workflow do not need the same boundary. Segment the client book by what the workflows actually touch, put the expensive isolation where the consequence is, and then spend your review time on the two things that fail across every tenant simultaneously — the encryption key and the version pins — because almost nobody reviews those and everybody reviews the workflows.
Related
- Governed workflow automation — the complete guide
- Relay.app closes on 14 September 2026: what to do with the time left
- Workflow portability: what to ask before you commit to a platform
- What permissions should an AI agent hold?
- How to build an audit trail for AI agents
BarzelOps is built for this shape of problem: multi-client workspace management for agencies and MSPs, tenant isolation with signed evidence receipts, request-scoped credential memory that is excluded from storage, and a portable Governed Workflow Manifest so a client's workflows can leave with them. The credential design is the part relevant to the section above — a credential held only for the duration of a request, and never written to the store, cannot be lost with an encryption key or recovered from a backup. To be explicit about the term, since this article has spent several hundred words on what vendors actually mean: Governed Workflow Manifest is Real Biz Digital's own name for a portable definition format. It is not an industry standard — no such standard exists.
In practice
Automation you can leave, with the approvals and the evidence intact.
A workflow platform is only as safe as your ability to leave it. BarzelOps runs cross-system workflows with durable state, human checkpoints and signed evidence, exports them as a portable manifest, and migrates Relay workflows with a dry run before cutover.
BarzelOps
Governed workflow automation across the systems that run the business.
- Durable, idempotent execution: a timeout is retried once, never filed twice.
- Human approval checkpoints that pause the workflow and resume it.
- Isolation per entity or client, signed evidence receipts and a portable manifest; HubSpot, Xero, Gmail, Google Drive and Slack.
Free tier: 100 calls a dayPaid plans from $19 a monthLive on MCPize
BarzelVault
The AI action firewall: decide what an agent may do before it does it.
- Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
- Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
- Credential isolation, spend and action limits, and an emergency kill switch.
Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize
Enterprise: written quote by email within two business days. No sales call.
Sources
- n8n community forum — practitioner thread on running an isolated instance per client from a shared stack; source of the credential, blast-radius, encryption-key and version-pinning quotations. A practitioner account, not vendor documentation.
- n8n documentation, Projects — scoping of workflows and credentials together, per-project roles, plan availability, and the requirement that credentials move with workflows.
- Wednesday Solutions — consultancy write-up on multi-tenant automation: billing attribution, secrets sprawl into version control, and the discipline shared-instance designs require.
- Zapier, Automation platform information — workspaces, connection and action controls, RBAC, audit logs, Asset History and log streaming; Zapier Community — official staff response on on-premises availability.
- Workato documentation, Security, Environments and On-prem agent — roles, audit log, encryption, residency, and the agent's connectivity-bridge architecture.
- Make, Security — SOC 2 Type II, SOC 3, ISO 27001 at Enterprise, RBAC and isolated AWS environment.
- relay.app shutdown notice and docs.relay.app migration guidance, as published; TechCrunch, 17 August 2026, on the Google acquihire.
- Forrester, Predictions 2026: Automation.
This article is for information and does not constitute legal, security or procurement advice. Product capabilities, plan availability and dates are as published at 2 September 2026; verify each against the vendor's own current documentation, and test any isolation claim in your own environment before relying on it in a client contract.