Multiple Clients on One n8n Instance: Projects, Permissions, and the Limits of Separation

What n8n Projects deliver for client separation, which roles exist, and where a shared instance for clients falls short.

Hand-drawn sketch: A house with several rooms divided by curtains, one curtain in teal

n8n Projects group workflows and credentials and can be used to organizationally separate multiple clients or teams on the same instance, but they are an access-control feature on a shared instance, not full multi-tenant separation like separate servers. For simple internal separation this is often enough, but usually not for strict data-separation requirements between paying clients. As of: August 2026.

What do Projects actually deliver?

According to the n8n documentation, Projects group workflows and credentials into their own area and are available on all paid plans, but not in the Community Edition. A single user can have different roles in multiple projects, so a team member could, for example, be set up as an Editor in client project A and as a Viewer in client project B. Details are provided by the n8n documentation on working with Projects.

Which roles exist within a project?

Within a project, three roles are available: Admin, Editor, and Viewer, with clearly graded permissions. In addition to all workflows, credentials, and executions, the Project Admin also manages the project members and settings; the Editor may view, create, edit, and delete workflows, credentials, and executions, but cannot manage members; and the Viewer has only read access without the ability to run workflows manually. According to n8n, the Editor role is available on Pro Cloud and Self-hosted Enterprise, while the Viewer role is only available on the Enterprise tiers of Cloud and Self-hosted, as the n8n documentation on available roles describes.

Where does the separation stop technically?

Projects separate access, not the underlying infrastructure: all projects on an instance run on the same n8n installation, the same database, and the same server resources. An error, a crash, or an overloaded queue in one client project can therefore affect the executions of all other projects on the same instance, even though clients cannot see each other's workflows and credentials. According to the documentation, moving resources also removes all existing sharing, which is easily overlooked when restructuring client projects.

When is a shared instance no longer enough?

A shared instance with Projects is generally sufficient as long as it's about organizational overview within your own team, not hard guarantees toward paying clients. As soon as a client demands dedicated resource guarantees, a separate version, downtime independent of other clients, or contractual data separation, a dedicated instance per client is the more reliable solution. This question is closely tied to the licensing question, as covered in the article about Hosting for clients and the n8n license.

Practical recommendation for agencies and internal teams

For internal team or department separation within a company, Projects are usually the more pragmatic choice because they don't require additional infrastructure. For agencies running n8n for multiple external clients, however, a dedicated instance per client, or at least per client group with a similar risk profile, is recommended in most cases. We support the decision and the setup of the right structure as part of our n8n services.

Frequently asked questions about client separation in n8n

Is n8n Projects also available in the Community Edition?

No, according to the n8n documentation, RBAC with Projects is available on all plans except the Community Edition. A pure self-hosted setup without a paid plan therefore lacks this separation option.

Can a user have different roles in different projects?

Yes, according to n8n a user can take on different roles in different projects, for example Editor in one and Viewer in another. This allows finer control than a single global role for the entire instance could.

What happens to existing shares when I move a workflow to another project?

According to the n8n documentation, moving a workflow or credential to another project removes all existing shares. The target project may then need renewed access to the required credentials, otherwise the moved workflow may no longer run correctly.

Do I necessarily need a separate n8n instance for every client?

Not necessarily; for simple internal separation or clients with a low risk profile, Projects can be sufficient. As soon as it's about contractual guarantees, independent failover, or strict data separation between clients, a dedicated instance per client is the safer choice.

Simon Glowik, founder of NordFlux
About the author

Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.

Certifications

  • Microsoft certified — PL-900 and AZ-900
  • UiPath certified — Automation Developer Associate
  • UiPath zertifiziert — Automation Developer Associate
All articles
Free initial call

Concrete questions about automation or AI?

In a free 30-minute initial call we discuss your case directly. No strings attached.

n8n Client Separation: Projects and Their Limits