Multi-Client n8n for Agencies: Isolate Credentials or Inherit Incidents

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 and 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. Across 500+ automations, the blast radius that hurts is almost never the canvas. It is the credential store.

The short answer

• Folders ≠ isolation. Registered Community unlocks folders for tidy canvases. Folders do not sandbox credentials or executions. See compare editions.
• Default for agencies: instance-per-client, or client-owned Cloud, when clients bring their own OAuth.
• Projects / RBAC: a collaboration boundary on plans that include them — not a substitute for tenancy, and not a settled Community feature as of August 2026. Cross-check organize work in projects against the edition page before you promise it.
• License: the Sustainable Use License covers internal use and consulting. Hosting clients’ workflows and credentials on your instance is an Enterprise conversation in n8n’s license FAQ. Embedding the editor is a separate OEM / Embed agreement.
• 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, executions, or OAuth tokens.

n8n is explicit about what registration buys. The community edition features page says unregistered Community is the free product with no license key. Registering your email unlocks folders, debug-in-editor, and custom execution data. That is workspace hygiene. It is not a tenant wall.

Approach	Credential boundary	When it is honest
Folders on one Community instance	Weak / none	Solo ops, one company, zero client logins
Projects + RBAC on a plan that includes them	Stronger per project	Your team collaborates; you verified the edition matrix this month
Instance per client	Strong	Clients connect Google / Microsoft; blast radius must stay local
Client-owned Cloud or 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.

Folders also fail the forensics test. A folder named acme/ does not stop an instance owner from viewing every credential. It does not stop a shared Google OAuth client from minting tokens into one database. It does not stop Client B’s webhook from landing on Client A’s path because someone copied the production URL.

Checklist before you call a shared box “isolated”:

• A user who should only see Client A cannot open Client B’s credentials
• Instance Owner / Admin accounts are named, few, and not handed to contractors
• No shared “agency Google” or “agency Microsoft” used for production mail or Drive
• Webhook paths or hosts encode a tenant id
• Offboarding is “delete the box” or “wipe the project and rotate every secret,” not “we’ll clean folders later”

If any box is unchecked, stop selling the folder tree as tenancy.

Do Projects create tenancy as of August 2026?

Hedge this. Two official n8n pages do not say the same thing, and plan grids move.

Compare editions lists Projects among features the Community edition does not include, next to SSO, credential sharing, external secrets, and Git environments. It tells you to treat the pricing page as the source of truth because “exact features per plan and edition can change.”

Organize work in projects currently says RBAC is available on n8n Cloud: all plans and self-hosted: Registered Community, Business, Enterprise, with different plans getting different numbers of projects and roles.

As of August 2026, do not write a sales deck that says “Community has no Projects” or “Registered Community is multi-tenant.” Screenshot both pages, date them, and confirm against pricing for the edition you are actually running.

What Projects do when they exist:

Project fact (docs, Aug 2026)	Isolation implication
Workflows and credentials group into a project	Better than folders for “who can see this canvas”
A user can hold different roles in different projects	Useful for agency staff; still one instance
Instance owners and admins create projects	Those roles sit above project walls
Moving a workflow or credential revokes existing sharing	Easy to break a live rail during a “cleanup”
Variables and tags are global	Names, IDs, and helper values leak across projects

Credential sharing is documented as available on n8n Cloud: all plans and self-hosted: Business, Enterprise. Shared users can use a credential without seeing the secret. Instance owners and admins can view and share all credentials on the instance.

That last sentence is the agency trap. A project wall that an instance admin can walk around is a collaboration feature, not a tenancy feature.

Cloud project counts, as listed on pricing in August 2026 (they move — recheck before you model a year):

Cloud / listed plan	Shared projects on the public grid
Starter	1 shared project
Pro	3 shared projects
Business (self-hosted listing)	6 shared projects
Enterprise	Unlimited shared projects

One shared project is not an MSP topology. Three shared projects is a small internal team. Neither is “we host twelve clients on Community and call the folders Projects.”

Projects solve collaboration boundaries on a license that includes them. They do not auto-solve SUL vs Enterprise. They do not stop noisy-neighbor CPU. They do not make an instance Owner safe to hand to a client contractor.

When is instance-per-client mandatory?

Prefer a dedicated instance (or client-owned n8n Cloud) when any of these are true:

1. Clients complete OAuth consent screens (Google, Microsoft, HubSpot, and the rest).
2. Contracts require data separation or distinct subprocessors answers.
3. Clients need editor access.
4. One client’s webhook flood must not starve another’s executions on shared workers.
5. 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 and database
• Separate credential set (no shared “agency Google”)
• Webhook paths or hosts that include a tenant id
• Error alerts routed to that client’s channel plus your on-call
• Backup and restore story for that instance alone
• Named client owner after handoff
• Encryption key that is not reused across clients

Queue mode makes the last item non-negotiable. n8n’s queue mode docs require every main, worker, and webhook processor to share N8N_ENCRYPTION_KEY so workers can read credentials in the database. A shared fleet with one key and one database is one credential domain, no matter how pretty the project names are.

Signal	Shared instance is a lie	Dedicated instance is the honest default
Client OAuth	Tokens land in your DB	Tokens land in their DB
Client editor login	They can wander	They can only wander their box
Legal questionnaire	One subprocessor, many principals	One box per principal
Offboard	Forensic treasure hunt	Destroy the instance
Noisy neighbor	Shared CPU, queue, and execution table	Blast radius stays local

If you cannot staff a fleet of instances, do not “solve” that with folders. Shift the default to client-owned Cloud and sell outcomes plus a runbook, not a multi-tenant kitchen.

What license do you need before you host client credentials?

Read the license page, then the help-center FAQ, then email n8n. Do not invent a fourth source from a forum thread.

n8n is fair-code under the Sustainable Use License (source text also lives in the GitHub LICENSE). Files with .ee. in the name sit under a separate Enterprise license. Plain language from the 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.

The SUL page’s own backend examples matter for agencies:

SUL example (n8n docs)	Allowed?
Sync data you control, CRM to an internal database	Yes
Build a node or an integration between your product and n8n	Yes
Consulting: build workflows, custom features, or code n8n executes	Yes
Support: set up or maintain n8n on an internal company server	Yes
White-label n8n and charge customers for it	No
Host n8n and charge people to access it	No
Collect a user’s HubSpot credentials so your app can pull their HubSpot	No
Backend chatbot that uses your company credentials; users only type questions	Yes

n8n’s help center FAQ frames commercial licensing like this:

Your model	What to verify with n8n
Consulting on client-owned instances	Often no commercial license for the agency; the client’s own plan or edition still applies
Hosting and 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, n8n.io/oem)
Backend-only (users never see n8n) inside your product	OEM docs distinguish this from Embed; the help center still flags client-credential hosting as Enterprise. Confirm in writing.

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.

The help center is also explicit that the helpdesk cannot grant permission for your use case. license@n8n.io is the path. Put the reply in the SOW folder next to the MSA.

License activation is not a vibe. Manage your license is Settings → Usage and plan → Enter activation key, or N8N_LICENSE_ACTIVATION_KEY on a fresh box. Paid self-hosted keys ping n8n’s license server. If you air-gap a client, ask n8n how that ping works before you promise an offline fleet.

Embed, OEM, and backend — hedge as of August 2026

As of August 2026, n8n’s own pages draw the Embed line in slightly different places. Treat that as a reason to get a written answer, not as a reason to pick the friendliest paragraph.

Deploy as an OEM integration says OEM needs a separate commercial agreement. OEM is embedding the n8n interface in your product so users build workflows without leaving your UI. n8n branding stays visible. The same page says backend use — your product calls n8n by webhook or API, users never see the editor — is available on all paid plans under the standard license, with no separate OEM agreement.

n8n.io/oem repeats the split: backend on a regular Enterprise license; OEM when you expose the canvas. OEM pricing is execution-commit and commercial. Do not invent a dollar figure here.

The license FAQ still says hosting and managing clients’ workflows and credentials on your instance is an Enterprise conversation, and exposing those workflows to clients is an Embed conversation.

Forum threads argue about tokens passed at runtime versus tokens stored in n8n. Some answers say a vault-plus-webhook still counts as processing client credentials. SUL’s HubSpot example is the conservative reading: if n8n uses the user’s third-party credentials, you are off the free license. Get n8n to apply that sentence to your architecture.

Pattern you are selling	Safer reading as of Aug 2026	Still do this
You build on their Cloud or self-host; they hold admin	Consulting; agency often needs no commercial license	Confirm the client’s edition for SSO, sharing, Projects
You host their workflows and their OAuth on your box	Help center → Enterprise	Email license@n8n.io; keep the reply
Users never see n8n; your product triggers workflows	OEM docs → paid plan, not OEM	Still confirm if those workflows use client credentials
Users edit canvases inside your product	OEM / Embed agreement	Do not ship an iframe and hope
You charge a monthly “hosted n8n” seat	SUL calls this out as not covered	Stop the landing page until sales@ answers

If your offer is “automation outcomes” and the client never logs into n8n, you are still not automatically SUL-clean. The deciding question in n8n’s own examples is whose credentials the nodes use, not whether the editor is visible.

How do you keep OAuth from bleeding across clients?

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 an over-broad admin role sees too much.

Safer patterns:

1. Client-owned n8n — the client creates the OAuth client; you never hold long-lived tokens on a shared box.
2. Instance-per-client — the OAuth redirect stays on that client’s hostname.
3. End-user credentials — only where the plan supports them, and only for the problem they actually solve (below).

Never paste client refresh tokens into Slack. Never reuse one “agency” Google account across clients for production mail or Drive.

OAuth choice	What you just accepted
One GCP project, many client consents, one n8n	One breach review for every tenant
Per-client GCP / Azure app, shared n8n	Better app isolation; tokens still cohabitate
Per-client app and per-client n8n	The default that survives a contractor with Owner
Agency service account “for convenience”	You are now in every client’s Drive

Redirect URI checklist:

• Production redirect matches the instance hostname, not a leftover ngrok
• Test and production OAuth clients are separate
• Client secret lives in the client vault, not in a Notion page
• Consent screen lists the client’s name, not your agency’s sandbox
• Offboard includes deleting or transferring the OAuth app, not just the n8n user

If a client must connect Google and you are still on one Community box, you are choosing the inherited-incident path. Redesign before the next onboarding.

Are end-user credentials a multi-client answer?

Usually no. They solve a different problem.

End-user credentials are documented as Enterprise on Cloud and self-hosted, and they are in preview as of the current docs. A project admin creates a template (OAuth client id and secret). Each user connects their own account. n8n resolves the triggering user’s connection at runtime. Execution data for those nodes is redacted from other users, including instance admins. Sharing the credential shares the template, not the connection.

That is a team-inbox feature. It is not an MSP tenancy feature.

End-user credential fact	Why agencies still need instance isolation
Enterprise only, preview	Do not promise it on Community or Starter
OAuth types only	API keys and service accounts stay fixed credentials
Triggers listed: manual, Chat Hub, MCP Server Trigger	Most agency webhooks are not on that list
Deleting the template deletes every user connection	One angry cleanup wipes the fleet
Instance still holds the OAuth client secret	The template is still your (or their) app registration

Use end-user credentials when one client’s employees should each connect Gmail without sharing one mailbox. Do not use them as the story for “twelve companies on one Community instance.”

Credential overwrites are an OEM-adjacent tool: set OAuth client details globally so end users authenticate without seeing client secrets. That is a product-embed pattern. It assumes you already have the commercial agreement that allows the pattern.

How should webhook paths encode tenant identity?

Shared infrastructure without tenant ids in URLs is how you debug the wrong customer.

The Webhook node lets you set a path, including route parameters (/:variable, /path/:variable). Use that. Do not ship every client to /webhook/lead-intake.

Pattern	Example	Use when
Path segment	/webhook/acme/lead-intake	One instance you have already licensed for multi-client work
Route param	/webhook/:tenant/lead-intake	You will reject unknown tenant values in the first nodes
Host	n8n-acme.youragency.com/webhook/lead-intake	Instance-per-client or dedicated webhook hostname
Verification	Per-tenant HMAC or header auth	Always — path slugs are not a secret

n8n’s webhook node supports Basic auth, header auth, JWT, an IP allowlist, and an Only Run If expression. Path-plus-secret is the minimum. Path alone is security theater.

Reject requests that cannot prove tenant. Log tenant id on every execution for forensics.

Also keep test and production URLs straight. The node exposes both. A client who bookmarks the test URL will miss production traffic, or worse, a leftover listen-for-test will surprise you in a demo. Production registers when you publish the workflow.

If you run queue mode with webhook processors, n8n’s load-balancer split matters: /webhook/* and /webhook-waiting/* to the processor pool; /webhook-test/* and the editor API to main. A shared processor pool in front of a shared database is still one tenant domain.

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 project role	Paid plan roles exist; the client cannot open other projects; you verified role availability
Full editor on shared Community instance	Not safe for multi-client
Full editor on their instance	Normal consulting model

Instance roles sit above projects. Owner and Admin can view, edit, and share all credentials. n8n even tells owners to keep a second Member account for building, because Owner work is hard to attribute. The Admin instance role is not on every plan — docs currently list it on Cloud Pro / Enterprise and self-hosted Enterprise.

Project roles, when your plan includes them:

Permission	Admin	Editor	Viewer
View workflows, credentials, executions	Yes	Yes	Yes
Edit and add workflows / credentials	Yes	Yes	No
Execute workflows	Yes	Yes	No
Manage members / modify the project	Yes	No	No

Viewer is documented as Cloud Enterprise and self-hosted Enterprise. Editor is documented as Cloud Pro and self-hosted Enterprise. If your deck says “we’ll give the client Viewer on Community,” you are inventing a role.

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.

Access checklist:

• No client user is instance Owner on a shared box
• Contractors get time-boxed accounts, not a standing Admin
• SSO is on if the edition includes it and the client’s IdP is ready
• Quarterly access review is on a calendar, not a wish
• Offboard day removes agency SSO and every agency user the same afternoon

What happens when clients share workers?

Even with separate projects on one paid instance, executions still compete for CPU, queue workers, and database IO.

Queue mode is a concurrency topology: main accepts the webhook, Redis holds the job, a worker reads the workflow from the same database and the same encryption key. Adding workers scales throughput. It does not create tenants.

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
• One tenant’s “Respond to Webhook” body is large enough to pressure Redis (n8n documents a relay size cap and offload path on recent versions)

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.

Shared-resource failure	What the other client sees	Honest mitigation
CPU pegged on a transform	Webhook latency, UI freeze	Dedicated instance or a hard concurrency cap plus an MSA clause
Execution table growth	Slow editor, disk alerts	Retention policy per instance; do not “just raise disk”
Redis full of large responses	Failed responds, worker errors	Offload or split the hot tenant
One encryption key leaked	Every credential on the fleet	One key per client instance

Community includes queue mode. Multi-main high availability does not — that is a paid edition feature on the compare editions page. Do not tell a client that “we run queue, so you are isolated.”

How do you update many client instances?

Fleet ops without a plan becomes unpaid weekends.

1. Pin n8n versions. Upgrade a canary instance first.
2. Keep workflow JSON in git per client. Credentials never go in git.
3. Maintain a matrix: client → version → last upgrade → owner → license key location.
4. Automate only what you will monitor. Blind mass upgrade is an outage multiplier.
5. Read release notes for breaking node changes before the fleet moves.
6. Confirm the license ping still succeeds after the upgrade (manage your license).

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.

Fleet habit	Why it exists
Canary client first	One broken node change beats twelve
Same minor pin across a wave	Mixed majors on one weekend is chaos
Encryption key in the same vault as the DB password	A SQL dump without the key is not a restore
Changelog read before the wave	n8n majors move webhook and queue behavior
Rollback image digest saved	Bravery is not a restore strategy

Do not “save time” by sharing one database across clients so upgrades are a single Postgres migrate. That is the isolation decision again, wearing an ops hat.

What belongs in a client handoff package?

When the engagement ends or moves to retainer-light, treat the day as a security event.

• Workflow exports (JSON)
• Credential inventory (names + which system — the client re-enters secrets)
• Webhook URL list and provider-console remaps
• Runbooks for each production rail
• Error-alert destination transfer
• Admin users removed; agency SSO gone
• OAuth apps: transfer or recreate under the client’s GCP / Azure
• License and plan responsibility written down
• Encryption key and backup location transferred or destroyed
• DNS and TLS for the instance hostname transferred

Secrets move through a vault, not email. A JSON export is not a credential export. If you “helpfully” paste refresh tokens into the handoff doc, you just extended the incident window.

Handoff order that does not leave a hole:

1. Client confirms they can log in as Owner on their instance (or their Cloud).
2. You export workflows and the credential name list.
3. Client recreates credentials and proves one staging webhook.
4. You remap production URLs during an agreed window.
5. You remove agency users and rotate any secret you ever saw.
6. You send the written license note: who pays n8n now.

If step 1 is “they still log into our shared Community box,” you do not have a handoff. You have a hostage.

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.

A second, quieter version: you sold “hosted n8n for clients” on a Community box. A year later someone forwards n8n’s license FAQ to your buyer. Now you have an outage and a commercial cleanup. The SUL page tells you to email license@n8n.io when you are unsure. Unsure is the default for agency hosting. Email before the first invoice.

A third version: you did buy a plan with Projects, then handed the client instance Admin. They can see every credential. The project tree was decoration.

Write the incident you are unwilling to inherit, then pick the topology that makes that incident structurally hard.

New-client onboarding checklist

Do this before the first production webhook goes live:

1. License posture written down — client-owned instance vs agency-hosted. If agency-hosted, commercial terms confirmed with n8n.
2. Instance provisioned — hostname, TLS, backups, admin 2FA. Separate database. Separate encryption key.
3. Credential policy — client OAuth only on that instance; no shared agency Google for production.
4. Webhook tenant id — path or host reserved; HMAC or header secret stored in the client vault.
5. Error workflow — client channel plus agency on-call; severity agreed.
6. Runbook stub — purpose, pause, irreversible steps, owners.
7. Staging twin or dry-run flag — prove failure cases before money paths.
8. Access list — who has Owner / Admin today; calendar reminder to prune quarterly.
9. Edition screenshot — compare-editions + pricing + Projects page, dated, in the project folder.
10. Offboard rehearsal — you can name the steps you will run on the last day.

Skipping step 1 to “move fast” is how agencies inherit both an outage and a licensing cleanup.

Decision worksheet

1. Do clients ever log into n8n?
2. Do we store client OAuth tokens on our infra?
3. Is this sold as “access to n8n” or “automation outcomes”?
4. Community, Registered Community, or a paid edition — which features do we actually need (Projects, SSO, sharing, Viewer)?
5. Have we emailed n8n about this model if (2) or (3) is fuzzy?
6. Instance-per-client cost and ops vs shared paid Projects — who pays for incidents?
7. As of this month, do the Projects and compare editions pages still agree?

If (1) or (2) is yes on a shared Community box, stop and redesign before the next onboarding.

If (3) is “access to n8n,” you are in SUL’s “charging people to access it” sentence until n8n says otherwise.

If (5) is “we will email later,” you do not have a product. You have a hope.

What we could not confirm without n8n sales

Be explicit with clients:

• Exact dollar pricing for Enterprise / OEM — not published here; ask n8n. Public Cloud stickers on pricing as of August 2026 listed Starter around €20 / month and Pro around €50 / month on annual billing. Those move.
• Whether your specific “we run outcomes only, clients never see the UI” hosting pattern is SUL-ok or Enterprise-required — forum anecdotes conflict; the help center FAQ leans Enterprise when client workflows and credentials live on your instance. OEM docs lean “paid plan, not OEM” when users never see the editor. Get it in writing for your SOW.
• Whether Registered Community includes Projects on self-hosted this month — the Projects page and the edition page disagree as of August 2026. Screenshot both.
• Which Cloud plan tiers include how many Projects — see current pricing; we do not freeze a grid that n8n can change tomorrow.
• Whether passing client tokens at runtime (vault → webhook → node) is treated as “using the user’s credentials.” SUL’s HubSpot example is the conservative read. Confirm.

Wrong legal guidance is worse than a slow onboarding. When unsure, email license@n8n.io.

FAQ

Do n8n Projects isolate credentials on community licenses?

Not as a tenancy story you can sell. Compare editions still lists Projects as outside Community, while the Projects page currently mentions Registered Community on self-hosted. As of August 2026 those pages disagree, so verify the edition you run. Even when Projects exist, instance Owner and Admin can see every credential, and folders never were a wall.

What about Embed / commercial options?

Embedding the n8n editor in your product requires a separate OEM / Embed commercial agreement; OEM docs and n8n.io/oem are the public starting points. Hosting clients’ workflows and credentials on your instance is an Enterprise conversation in the license FAQ. Backend-only use is documented as a different path on paid plans — still confirm if those workflows use client credentials, and email license@n8n.io / sales@n8n.io for prices; we do not publish them.

How do I update many client instances?

Canary first, pin versions, track a client × version × license matrix, keep workflow JSON in git without secrets, and refuse blind fleet upgrades. Confirm the license activation still pings after the wave. If you cannot staff that, reduce fleet size or shift clients to Cloud, where upgrades are someone else’s pager — and still write down who clicks promote.

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. The Webhook node supports path variables plus Basic, header, or JWT auth. 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 on 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, and Viewer / Editor are not on every plan. Instance Admin on a shared box is not “safe access.” It is a master key.

What belongs in a client handoff package?

Exports, credential name inventory, webhook remap list, runbooks, alert ownership, admin removal, OAuth app transfer, and the encryption-key / backup story. Write who holds the n8n license after you leave. Secrets move through a vault, not email. If they still authenticate to your shared Community box, you have not handed off.

CTA

Isolate credentials first — license second — folders never.

For agency production design on n8n, start with the handbook, then use automation or book a $500 Automation Audit.