Multi-Client n8n for Agencies: Isolate Credentials or Inherit Incidents
Agencies isolate n8n by instance or paid Projects — folders are not tenancy, and hosting client credentials needs a verified license check with n8n.
Agencies and MSPs should assume mixed credentials on one community instance are an incident waiting for a wrong OAuth consent. Isolation means separate credential boundaries — usually instance-per-client, or paid n8n Projects/RBAC on a license that actually includes them — not folders with optimistic naming. Licensing is a fair-code minefield: confirm your model with n8n before you sell “hosted n8n for clients” as a product.
Spurlock Studios builds client rails with the same production spine as the Production n8n handbook. Hosting choice still matters — see self-hosted vs n8n Cloud — but multi-tenant design is a separate decision.
The short answer
- Folders ≠ isolation. Community edition has no Projects and no credential sharing model that creates tenancy.
- Default for agencies: instance-per-client (or client-owned Cloud) when clients bring their own OAuth.
- Projects/RBAC: available on paid plans, not on Community (community edition features).
- License: Sustainable Use License is for internal/consulting patterns; hosting clients’ workflows/credentials on your instance or embedding the editor needs a commercial conversation with n8n — do not invent pricing.
- Offboarding: revoke access, rotate secrets, export runbooks, kill webhooks — same day the contract ends.
One instance with folders — is that isolation?
No. Folders organize canvases. They do not sandbox credentials or executions.
| Approach | Credential boundary | When it is honest |
|---|---|---|
| Folders on one Community instance | Weak / none | Solo ops, one company, zero client logins |
| Projects + RBAC (paid) | Stronger per project | Your team collaborates; plan includes Projects |
| Instance per client | Strong | Clients connect Google/Microsoft; blast radius must stay local |
| Client-owned Cloud / self-host | Strongest for consulting | You build; they hold the keys |
If a client admin can open another client’s credential, you do not have multi-tenant isolation. You have a shared kitchen.
When instance-per-client is mandatory
Prefer a dedicated instance (or client-owned n8n Cloud) when any of these are true:
- Clients complete OAuth consent screens (Google, Microsoft, HubSpot, etc.)
- Contracts require data separation or distinct subprocessors answers
- Clients need editor access
- One client’s webhook flood must not starve another’s executions on shared workers
- Offboarding must be “delete the box,” not “hunt for leftover credentials”
MSP posture from the community is blunt for a reason: each client gets their own instance when you are in the trust business.
Minimum per-client bar:
- Separate n8n URL / database
- Separate credential set (no shared “agency Google”)
- Webhook paths that include a tenant id
- Error alerts routed to that client’s channel + your on-call
- Backup/restore story for that instance alone
- Named client owner after handoff (ownership & runbooks)
Licensing: confirm before you productize
n8n is fair-code under the Sustainable Use License (and a separate Enterprise license for .ee. features). Plain language from n8n’s docs: internal business use and consulting are in bounds; white-labeling n8n or charging people to access a hosted n8n are called out as not covered by SUL.
n8n’s help center FAQ (commercial licensing overview) frames it roughly as:
| Your model | What to verify with n8n |
|---|---|
| Consulting on client-owned instances | Often no commercial license for the agency; client’s own plan/edition still applies |
| Hosting/managing clients’ workflows and credentials on your instance | FAQ points to Enterprise — confirm for your facts with license@n8n.io / sales@n8n.io |
| Embedding the n8n editor in your product UI | Separate OEM / Embed agreement (OEM deploy docs) |
| Backend-only (users never see n8n) inside your product | Docs distinguish this from OEM; still confirm plan/license for your distribution model |
We are not your lawyer and this is not a license grant. Feature matrices and commercial terms change — check n8n pricing and email n8n when your agency model sits near a boundary. Do not ship a sales deck that asserts SUL covers multi-tenant client hosting without their confirmation.
Do Projects isolate credentials on Community?
No. Official docs: Community edition does not include Projects or workflow/credential sharing (compare editions). RBAC/Projects are documented as available on plans except Community (organize work in projects).
On a paid plan that includes Projects, credentials live with the project and roles bound who can use them — that is real isolation within that license. It is still not a substitute for reading whether your agency hosting model is allowed. Projects solve collaboration boundaries; they do not auto-solve SUL vs Enterprise.
Google OAuth without cross-tenant bleed
Agency anti-pattern: one Google Cloud OAuth client, one redirect URI, many client consents into one n8n. Tokens land where the instance lives. A confused deputy or over-broad admin role sees too much.
Safer patterns:
- Client-owned n8n — client creates OAuth client; you never hold long-lived tokens on a shared box
- Instance-per-client — OAuth redirect stays on that client’s hostname
- End-user credentials (where your plan supports them) — user connects their account without sharing the underlying secret with every editor; still confirm plan features on pricing
Never paste client refresh tokens into Slack. Never reuse one “agency” Google account across clients for production mail or Drive.
Webhook paths that encode tenant identity
Shared infrastructure without tenant ids in URLs is how you debug the wrong customer.
| Pattern | Example |
|---|---|
| Path segment | /webhook/acme/lead-intake |
| Host | n8n-acme.youragency.com/webhook/lead-intake |
| Verification | Per-tenant HMAC secret (webhook security) |
Reject requests that cannot prove tenant. Log tenant id on every execution for forensics.
Updating many client instances
Fleet ops without a plan becomes unpaid weekends.
- Pin n8n versions; upgrade a canary instance first.
- Keep workflow JSON in git per client (credentials never in git).
- Maintain a matrix: client → version → last upgrade → owner.
- Automate only what you will monitor — blind mass upgrade is an outage multiplier.
- Read release notes for breaking node changes before the fleet moves.
If you cannot staff fleet upgrades, prefer client-owned Cloud where the vendor’s upgrade path is part of what they buy — still document who clicks promote.
Can clients get editor access safely?
| Access level | Safe when |
|---|---|
| No editor (you operate) | Outcomes-only delivery; credentials stay with you under a license that allows your model |
| Viewer / limited role | Paid plan roles exist; client cannot open other projects |
| Full editor on shared Community instance | Not safe for multi-client |
| Full editor on their instance | Normal consulting model |
If a client needs the canvas, put them on their instance or a commercial setup n8n has blessed for that access pattern. Do not hand Community owner keys on a shared box.
Client handoff package
When the engagement ends or moves to retainer-light:
- Workflow exports (JSON)
- Credential inventory (names + which system — client re-enters secrets)
- Webhook URL list + provider console remaps
- Runbooks for each production rail
- Error alert destination transfer
- Admin users removed; agency SSO gone
- OAuth apps: transfer or recreate under client GCP/Azure
- Confirm license/plan responsibility written down
Offboarding day is a security event. Treat it like one.
Decision worksheet
- Do clients ever log into n8n?
- Do we store client OAuth tokens on our infra?
- Is this sold as “access to n8n” or “automation outcomes”?
- Community or paid edition features required (Projects, SSO, sharing)?
- Have we emailed n8n about this model if (2) or (3) is fuzzy?
- Instance-per-client cost/ops vs shared paid Projects — who pays for incidents?
If (1) or (2) is yes on a shared Community box, stop and redesign before the next onboarding.
Failure mode: inherited incidents
What breaks: Client A’s contractor is still an admin. They browse credentials, rotate the wrong Google connection, Client B’s nightly sync dies. Your agency owns the apology tour.
Cost: trust, possibly contract clauses, and a week of forensic exports. Isolation is cheaper than the postmortem.
New-client onboarding checklist
Do this before the first production webhook goes live:
- License posture written down — client-owned instance vs agency-hosted; if agency-hosted, commercial terms confirmed with n8n.
- Instance provisioned — hostname, TLS, backups, admin 2FA.
- Credential policy — client OAuth only on that instance; no shared agency Google for prod.
- Webhook tenant id — path or host reserved; HMAC secret stored in the client vault.
- Error workflow — client channel + agency on-call; severity agreed.
- Runbook stub — purpose, pause, irreversible steps, owners (see ownership post).
- Staging twin or dry-run flag — prove failure cases before money paths (staging).
- Access list — who has owner/admin today; calendar reminder to prune quarterly.
Skipping step 1 to “move fast” is how agencies inherit both an outage and a licensing cleanup.
Shared workers and noisy neighbors
Even with separate projects on one paid instance, executions still compete for CPU, queue workers, and database IO. Instance-per-client isolates blast radius when:
- One client runs heavy binary transforms
- Webhook retries stampede a single base URL
- A runaway loop fills the execution table
If you keep a shared fleet for cost reasons, document the noisy-neighbor risk in the MSA. Isolation is partly legal language, not only folders.
What we could not confirm without n8n sales
Be explicit with clients:
- Exact dollar pricing for Enterprise / OEM — not published here; ask n8n.
- Whether your specific “we run outcomes only, clients never see the UI” hosting pattern is SUL-ok or Enterprise-required — forum anecdotes conflict; help center FAQ leans Enterprise when client workflows and credentials live on your instance. Get it in writing for your SOW.
- Which Cloud plan tiers include how many Projects — see current pricing; we do not snapshot plan grids that change.
Wrong legal guidance is worse than a slow onboarding. When unsure, email license@n8n.io.
FAQ
Do n8n Projects isolate credentials on community licenses?
No. Projects and credential/workflow sharing are not part of the Community edition per n8n’s edition comparison docs. On Community, only the instance owner and the creating user can access those resources — there is no project tenancy layer. Use separate instances or a paid plan that includes Projects, and still separate clients when OAuth tokens must not cohabitate.
What about Embed / commercial options?
Embedding the n8n editor in your product requires a separate OEM/Embed commercial agreement with n8n; backend-only use is documented as a different path. Hosting clients’ workflows and credentials on your instance is called out in n8n’s licensing FAQ as an Enterprise conversation. Check current terms on n8n’s OEM page, pricing, and with license@n8n.io / sales@n8n.io. We do not publish prices here — they are commercial and change.
How do I update many client instances?
Canary first, pin versions, track a client×version matrix, keep workflow JSON in git without secrets, and refuse blind fleet upgrades. If you cannot staff that, reduce fleet size or shift clients to environments where upgrades are someone else’s pager.
How should webhook paths encode tenant identity?
Put a tenant slug in the host or path, verify with a per-tenant secret, and reject anonymous traffic. Shared generic /webhook/lead across clients is how you apply Client A’s CRM mapping to Client B’s payload.
Can clients get editor access safely?
Yes on their instance (or a commercial multi-tenant setup n8n has agreed to). Not on a shared Community instance with other clients’ credentials. Paid project roles help only inside a properly licensed, properly partitioned environment.
What belongs in a client handoff package?
Exports, credential name inventory, webhook remap list, runbooks, alert ownership, admin removal, and OAuth app transfer. Write who holds the n8n license after you leave. Secrets move through a vault, not email.
CTA
Isolate credentials first — license second — folders never.
For agency production design on n8n, start with the handbook, then use automation or book a call.
Keep reading.
Automation Build It Yourself or Hire: The Blast-Radius Test for Automations
DIY when side effects are reversible and a named owner will keep them. Hire when money, customers, or recovery paths are on the line — not by step count.
Automation Who Owns the Automation When the Builder Leaves
When the builder leaves, automations survive only if a named owner, a half-page runbook, and company-owned credential handoff are already in place.
Automation Airtable as an Automation Backend: Fine Until Rate Limits Become the Product
Airtable works as an automation backend until the 5 req/s ceiling and plan record caps force you to move the system of record — stop patching forever.