Does n8n support multi-tenancy?

Not in the way SaaS platforms mean it. n8n has no tenant primitive: no per-tenant database, no per-tenant encryption key, no per-tenant webhook host. The closest feature is Projects, which is a paid organizational layer inside one instance that groups workflows and credentials and controls who can see them. That is access control, not isolation. If your requirement is that one client's data can never be readable from another client's context, the boundary has to be the instance itself.

Can I run one n8n instance for multiple clients?

Yes, and plenty of agencies do it for their first few clients. It is defensible when you own all the data, no client ever receives a login, none of the workflows touch regulated data, and every client can tolerate the same upgrade window. It stops being defensible the moment a client needs their own access, their own retention rules, or a guarantee that a noisy workflow from someone else cannot stall theirs. One instance means one Postgres database, one encryption key, one restart and one blast radius.

Is n8n Projects enough to isolate agency clients?

No. Projects keeps people out of each other's workflows in the UI and scopes credentials to a group, which is genuinely useful for a team. But every project still shares the same database, the same N8N_ENCRYPTION_KEY, the same installed community nodes, the same webhook domain, the same version and the same restart. A credential is only encrypted at rest with that one shared key, so a database dump is a dump of everyone. Use Projects to organize your own team, not to promise a client isolation you cannot deliver.

How much does instance-per-client n8n cost to run?

Less than people expect, because n8n idles cheaply. A 2 vCPU / 4 GB VPS handles a typical client's few dozen workflows comfortably and runs in the twelve-to-twenty-five dollar a month range at most hosts. Ten clients is therefore a couple hundred dollars a month in infrastructure, with no per-execution fee, and you can put light clients on shared hardware with separate containers and databases. The real cost is not the servers, it is the fleet management you have to build once.

How do I push the same workflow to ten client n8n instances?

Treat workflow JSON as source code and deploy it, rather than exporting and importing by hand. Keep the workflows in a Git repository, keep every client-specific value in environment variables instead of hardcoded in nodes, and use n8n's public REST API to create or update the workflow on each instance from a single script. That gives you one place to review a change, a diff when something breaks and a rollback that does not depend on remembering what you clicked.

When should an agency move a client off a shared n8n instance?

Move them when any of four things becomes true: the client asks for their own login, the client's data has a retention or residency rule the others do not share, the client's workflows are heavy enough to make other clients wait, or the client is big enough that losing them to an outage you caused elsewhere would actually hurt. Do not wait for all four. Migrating one client is a quiet afternoon; migrating six after an incident is not.

n8n Multi-Tenant: One Instance or One Per Client?

The short answer

n8n has no real multi-tenancy, so for agency work you isolate at the instance level: one n8n instance per client, plus one control plane you own that watches the fleet. Projects, the feature everybody reaches for first, is a paid organizational layer inside a single instance. It groups workflows and credentials and decides who sees what in the UI. It does not give you a separate database, a separate encryption key, a separate webhook host or a separate blast radius. If a client's data must never be readable from another client's context, that is an instance boundary, not a folder.

We build and run n8n for clients for a living, and this is the question that comes up on nearly every kickoff call. Here is what we actually do and why.

What n8n gives you out of the box

Worth being precise, because a lot of blog posts are wrong about this. Per n8n's own edition comparison, the free Community edition includes almost the complete product — every node, unlimited workflows, unlimited executions, and queue mode for scaling. What it does not include:

Projects — the workspace grouping feature
Sharing of workflows and credentials (only the instance owner and the creator can see them)
External secrets (Vault, AWS Secrets Manager, 1Password Connect, and friends)
Environments and Git-based version control
SSO via SAML or LDAP
Custom variables, external binary storage, log streaming and multi-main mode

Registering your Community instance with an email is free and unlocks folders, debug-in-editor and custom execution data. That is it.

So on a free self-hosted instance you cannot even share a workflow with a teammate, let alone partition it by client. That single fact pushes most agencies toward one of two places: pay for a plan, or run more instances. Most of the advice online skips straight to "use Projects" without mentioning it is behind a paid tier — and without asking whether it solves the problem at all.

Why "just use Projects" isn't isolation

Projects is a good feature. We use it internally. But it is access control, and people sell it to clients as isolation. Inside one instance, every project still shares:

One Postgres database. Every client's execution data, including whatever payloads flowed through it, sits in the same tables.
One N8N_ENCRYPTION_KEY. Credentials are encrypted at rest with that single key. A database dump is a dump of everyone, decryptable with one secret.
One version and one restart. Upgrading for the client who needs a new node upgrades everybody, during the same window. Our post on rolling back a self-hosted n8n upgrade exists because that goes wrong more often than people admit.
One set of installed community nodes. A node one client needs is installed in the process every other client's workflows run in.
One resource pool. A Code node that eats memory is a Code node that eats everyone's memory. Queue mode softens this but does not remove it — see how many n8n workers you actually need.
One webhook host. Every client's third-party integrations point at the same domain.

None of that is a reason to avoid Projects. It is a reason not to write "isolated environment" in a proposal when what you have is a folder with permissions on it.

The three architectures agencies actually run

Shared instance, no separation. One box, everything in it, you own all the data and no client has a login. Cheapest and fastest. Honest answer: this is fine for your first three or four clients if none of them touch regulated data. It becomes a liability quietly — usually the first time a client asks to "see the automation."

Shared instance with Projects. Requires a paid plan. Real value for a team: your specialists stop tripping over each other and credentials stop leaking sideways between engagements. Still one database, one key, one upgrade. Good for organizing your people. Not a client-facing isolation story.

Instance per client. Each client gets their own container, their own Postgres database, their own encryption key, their own subdomain, and their own upgrade schedule. Costs more in operations and almost nothing in money. This is what we run for anyone whose data has rules attached to it, and for anyone who might one day want their own login.

There is a fourth thing people try — one instance, one mega-workflow, a clientId switch at the top routing to different branches. It works right up until it doesn't, and then it fails for every client at once. We have inherited that pattern twice. Both times the rescue was the same: split it.

What we run, and the numbers behind it

Instance per client, on small hardware, with a control plane we own.

A typical client's few dozen workflows sit comfortably on a 2 vCPU / 4 GB VPS, which runs somewhere between twelve and twenty-five dollars a month depending on the host. Self-hosted n8n has no per-execution fee, so that number does not move when the client's volume triples. Ten clients is a couple hundred dollars a month of infrastructure — less than a single seat of most marketing SaaS. Light clients can share hardware while still getting separate containers and separate databases, which keeps the boundary intact at a fraction of the box count.

Compare that to the paid plan you would buy purely to get Projects. Public 2026 write-ups put the self-hosted Business plan in the €600-a-month range; n8n's pricing page is the source of truth and the number moves. Either way, the plan buys you SSO, environments and external secrets — all genuinely useful — but it does not buy you the thing the instance boundary gives you for the price of a VPS.

The real cost of instance-per-client is not servers, it is fleet management. You need one place that knows whether twelve instances are alive, one place that catches a failed execution on any of them, and one way to ship a fix to all of them. Build that once and the model scales; skip it and you will be SSH-ing into boxes at 11pm. We wire every client instance's failures into a single alerting path, which is the same discipline described in n8n error handling and monitoring.

How to ship one workflow to twelve clients without copy-paste

Export-and-import by hand does not survive contact with a fleet. Treat workflow JSON as source code:

Keep workflows in Git. One repository, one directory per shared workflow, the JSON committed and reviewed like anything else. This is also how you get a diff when a workflow starts misbehaving. We wrote up the mechanics in n8n version control without Enterprise.
Push client-specific values into environment variables. No account IDs, no sheet URLs, no phone numbers baked into nodes. If the same JSON cannot run on two clients unmodified, it is not a shared workflow, it is two workflows.
Deploy over the public REST API. POST /api/v1/workflows to create and PUT to update, from a single script that loops over your instance list and their API keys. Deploy to one client first, watch it, then fan out.
Version what you shipped. Record which commit is live on which instance. When client seven behaves differently from client eight, that record is the first thing you will want.

One caveat that bites agencies specifically: n8n's license terms restrict hosting the product for other companies in some configurations. Read them before you sell managed instances — we covered the details in n8n's commercial license for agencies.

Webhooks and the client-facing domain problem

This one is underrated. On a shared instance every client's third-party integrations point at the same host, which means a client can see a URL that obviously belongs to your agency, and an integration you set up for client A lives on the same domain as client B's.

Per-instance, you set WEBHOOK_URL to a subdomain for that client and every registered webhook is theirs. The migration benefit is bigger than the cosmetic one: when a client leaves, or moves hosts, or gets their own instance, you repoint one subdomain instead of hunting down every webhook someone registered against a shared URL three years ago. Shared hosts are easy to enter and painful to exit.

When a shared instance is genuinely fine

Not everything needs a boundary. Stay shared when all of these hold:

You own the data. The client is buying an outcome, not a system.
No client ever gets a login.
No workflow touches health, financial or otherwise regulated data.
Every client can live with the same upgrade window.
Losing all of them to one bad afternoon would be survivable.

That describes a lot of early agency work, and pretending otherwise just burns money. The mistake is not starting shared. The mistake is staying shared past the point where one of those five stops being true, because migrating under pressure is where the outages come from.

If you are still deciding whether to self-host at all, we compared the tradeoffs in self-hosted n8n vs n8n Cloud for agencies — the multi-tenancy question is the main reason the answer usually comes out "self-host."

The one thing to take away

Pick your boundary before a client picks it for you. n8n will happily run every client you have in a single process, and it will do it well, right up to the day someone asks a question you cannot answer honestly. Deciding where the walls go while everything is calm costs you an afternoon. Deciding it during an incident costs you the client.

Running n8n for more than one client and not sure your setup holds up? Get a free automation audit — we will look at how your instances, credentials and webhooks are actually partitioned today and tell you plainly what would break, including the parts you would rather not hear. If you would rather we build and run the fleet, that is what our n8n automation practice does.