n8n Permissions End to End: Account Types, Project Roles, and the Community Cliff

If you have ever tried to answer the question “who can touch this workflow” in n8n and reached for a single list of roles, you were working with half the system. n8n does not have one ranked ladder of users. It has two independent axes: a global account type that every user has exactly one of, and a per-project role that can differ for the same user in every project they belong to. A person’s real, day-to-day access is the union of those two things, not the account type on its own.

That distinction is not pedantic. It is the difference between a correct mental model and a wrong one, and most third-party guides on n8n roles get it wrong because they only describe the account types. This piece walks both axes, shows how they combine, and then does the part that matters most for self-hosters: it spells out how much of this entire model simply does not exist on the free Community edition.

Everything here is checked against the n8n documentation on the main branch. As of June 2026 the current stable release is 2.23.3 (published 2026-06-04), with the 2.25.x line on the next and beta tags. Version gates are called out where they exist.

Two role systems, not one

n8n separates account types from role types. The docs state it directly: account types and role types are different things, and role types are part of RBAC. Hold onto three sentences and the rest of this article stays unambiguous:

• Every account has exactly one account type. The choices are Owner, Admin, and Member, and they apply across the whole instance.
• A user can hold a different project role in each project. The built-in project roles are Admin, Editor, and Viewer, plus custom roles on Enterprise.
• Effective access is the account type plus the project roles layered on top of it. Neither axis tells the whole story by itself.

The account type is the coarse, instance-wide setting. The project role is where most of the fine-grained, per-resource control lives for anyone who is not an instance Owner or Admin. Keep both in view.

The instance account types: Owner, Admin, Member

Here is the documented permission matrix for the three account types, reproduced from the account-types reference. Read it once with a specific question in mind: where is the real cliff?

The surprise is the top two rows of the matrix collapsing into one. Owner and Admin are identical on every documented permission except a single line: only the Owner can access the Cloud dashboard, which is a Cloud-only concept. On a self-hosted instance that one differing row does not apply to anything you do day to day, so the practical instance hierarchy is just two levels: “Owner or Admin” as one tier, and “Member” as the other.

The real drop is Admin to Member. A Member keeps their own email, password, workflows, and the ability to view, create, and use tags. Everything else in the matrix flips to No. A Member cannot view or share other people’s workflows, cannot view, edit, or share other people’s credentials, cannot use Source control, cannot create or even view projects, cannot add or remove users, and cannot delete tags. That is the line worth designing around.

What only the Owner can do

On Cloud, the Owner alone reaches the Cloud dashboard. On self-hosted there is no documented permission the Owner has that an Admin lacks, so the Owner’s special status is structural rather than permission-based: the Owner is the single bootstrap account for the instance. The docs describe one instance owner, and they recommend against doing your daily building work as that account.

Best practice: n8n recommends that an Owner create a member-level account for themselves. There is no way to see who created a workflow, so an Owner editing shared workflows risks silently overwriting someone else’s work. The super-account should administer, not author.

The license-activation and instance-settings flows sit outside this matrix, so this article does not assert who can or cannot enter a license key beyond what the matrix documents. Treat Owner and Admin as functionally equivalent on self-hosted unless your own instance settings prove otherwise.

What Owner and Admin share

Effectively everything in the matrix. Both can view and share all workflows, view, edit, and share all credentials, set up Source control, create and view all projects, add and remove users, and delete tags. If you need a second person with full instance-wide reach, the Admin account type is how you do it without making them the Owner.

There is a catch that reframes the whole topic for self-hosters: the Admin account type itself requires a paid plan. The user-management overview lists the account types as Owner and Member, with Admin available only on Pro and Enterprise plans. More on that in the Community section, because it is the load-bearing constraint there.

What a Member can and cannot do

A Member is scoped to themselves plus tags. Their own workflows and credentials, yes. Viewing, creating, and using tags, yes. Anything that touches another user’s resources, the project structure, source control, or user administration, no. A Member only gains broader reach by being given a project role inside a project, which is the next axis.

The project roles: Admin, Editor, Viewer, and custom

Inside a project, a user’s role governs what they can do with the resources in that project, independent of their account type. The three built-in roles map cleanly:

The * rows require an instance Owner or Admin to turn on “Enable external secrets for project roles”, and they are available from n8n 2.13.0. Before that version, using external secrets inside a project required an instance Owner or Admin to be a member of the project.

A Project Admin has full control of the project plus the two management powers: managing members and modifying project settings. A Project Editor has full create, read, update, and delete over workflows, credentials, and executions, but cannot manage members or change project settings. A Project Viewer is read-only.

The Viewer trap

The single row most people misread is “Execute workflows”. A Viewer cannot manually execute any workflow in the project. The docs are explicit that a Viewer is effectively read-only and cannot run anything by hand. If you hand someone the Viewer role expecting them to be able to trigger a run for testing or operations, they cannot, and that surprises teams who assumed “view” implied “run”. When someone needs to trigger workflows but should not edit them, the built-in roles do not cover that gap; you need a custom role with workflow:execute but not workflow:update.

Custom roles and the scope catalogue

Custom project roles let you assemble granular permissions instead of accepting the three presets. They are an Enterprise feature, available from n8n version 1.122.0 (released November 24, 2025). Instance Owners and Admins create them; Project Admins assign them within a project.

A custom role is built from permission scopes grouped by resource: workflow, credential, project, folder, execution, secret vault, secrets, data table, project variable, and source control. Two pairing rules are worth internalizing because they change what a checkbox grants:

• Granting <resource>:read also grants the matching list scope for that resource. For example, workflow:read also grants workflow:list.
• Granting workflow:publish also grants workflow:unpublish.

The “execute but not edit” role from the Viewer trap above is a representative example: workflow:read, workflow:execute, and project:read, with no workflow:update. For the full scope reference, including the exact codes you will see in API responses and audit logs, see the custom-roles doc.

What RBAC does not govern

A common false claim in third-party guides is that everything in n8n is project-scoped. It is not. The role-types reference states plainly that Variables and Tags are not affected by RBAC: they are global across the instance. A project role gives no control over them. Enterprise custom roles do add a separate per-project variable resource with its own projectVariable:* scopes, but that is a distinct thing from the instance-wide Variables feature; do not conflate the two.

How account type and project role combine

Effective access is the union of the global account type and the project role. Work through the three cases and the model clicks:

• Member + Project Editor. The user has no instance-wide reach. Inside that one project they can create, read, update, delete, and execute workflows, credentials, and executions, but cannot manage members or change project settings, and cannot touch anything in any other project.
• Member + Project Admin. This is how a non-Owner gets real power without being an instance Admin. Inside the project they control everything, including members and settings, while remaining a plain Member everywhere else. For most teams this is the correct way to delegate ownership of a workspace.
• Admin account type, any project role. An Admin already views and shares all workflows, and views, edits, and shares all credentials, across the entire instance. Their project role is mostly irrelevant, because their instance-wide access already covers most of what a project role would grant.

The practical consequence: project roles matter primarily for Members. For Owners and Admins they change almost nothing, because those accounts already reach the whole instance. If you are designing access for a team, you are mostly deciding two things: who needs the Admin account type at all (few people), and what project role each Member gets in each project (most of the real work).

What this looks like on the Community edition

This is the section most third-party material on n8n roles gets wrong for self-hosters, and it is the most important one to get right, because the free Community edition does not have most of the system described above.

What you get

On Community you get exactly one Owner with full access to everything, plus Members. Each Member sees and edits only the workflows and credentials they created; the Owner sees and edits all of them. That is the entire access model. There is no second axis.

What you do not get

The Community edition does not include Custom Variables, Projects, Sharing of workflows or credentials, SSO (SAML and LDAP), Environments, External secrets, external storage for binary data, log streaming, multi-main mode, or version control using Git. Queue mode itself is included; only the multi-main extension of it is gated. Logging is included; only log streaming is gated.

Because the Admin account type is gated to Pro and Enterprise, and because Projects and RBAC are gated entirely, there is no documented way on Community to give a second person full, instance-wide admin-equivalent access. The Owner is the only account that sees everything, and you cannot promote anyone to match it without a paid plan. For a team running production automations, that is a real continuity risk: there is no built-in second administrator, and no project structure to scope access. Plan for it before it becomes a problem, not after the one person with the Owner account is unavailable.

Note: You may see forum reports describing specific upgrade prompts when adding users on self-hosted Community. The documented constraints are the gating of Sharing, Projects, and the Admin account type, not a specific prompt. Treat the exact UI behavior as version-dependent and verify it on your own build rather than relying on second-hand accounts.

Registered Community changes none of this

You can register a free Community instance with your email and receive a license key. Registering unlocks Folders, Debug in editor, and Custom execution data. None of those are roles, and none of them change the access model: still one Owner, still Members who see only their own resources, still no Projects, no Admin account type, and no sharing. Once activated, the license does not expire, and n8n notes that any future change to the unlocked feature set will not remove features you already have.

Practical patterns without RBAC

If you are on Community and cannot scope access with projects and roles, the working patterns are operational rather than in-app:

• Isolate by instance. Run separate n8n instances for separate teams or trust boundaries instead of trying to partition one instance you cannot partition. The full reasoning, and a decision matrix for when roles are enough versus when you need separate instances, is in the RBAC and tenant isolation piece.
• Manage secrets at the infrastructure layer. Without External secrets, keep credentials out of the application’s reach where you can by injecting infrastructure secrets through environment variables and Docker secrets, and rely on the n8n credentials store only for workflow-level secrets. This is the same split worth applying even on paid plans.
• Treat the Owner as the super-account, deliberately. Document who holds it, build under member-level accounts where the recommendation applies, and have a recovery plan for the Owner credentials.

Plan and version gating: which capability needs which tier

The table below maps each capability to where it unlocks, taken strictly from the per-feature availability notes in the docs. A warning up front, because this is the part that goes stale fastest: exact plan names, seat counts, project counts, and prices live on the pricing page and change. Do not treat the specific tier names below as permanent; confirm them against pricing before you quote a number to anyone.

Two rows are worth flagging because guides often blur them. Workflow sharing and credential sharing do not unlock at the same tier: the workflow-sharing doc lists Pro and Enterprise Cloud plus Enterprise self-hosted, while the credential-sharing doc lists all Cloud plans plus Business and Enterprise self-hosted. They are separate features with separate availability, so do not assume that having one means you have the other.

Operational guidance and boundaries

A short tail of documented behaviors that bite people in practice:

• Build as a Member, even as the Owner. Repeating the recommendation from earlier because it has a concrete failure mode: there is no way to see who created a workflow, so authoring as the Owner risks overwriting shared work. Keep a member-level account for building.
• Moving a workflow or credential revokes its sharing. When a workflow or credential owner moves a resource to another project or user, n8n removes all existing sharing. The docs warn that this can break other workflows that were relying on the shared resource. Check what depends on a resource before you move it.
• SAML governs login, not user lifecycle. With SAML enabled, removing a user from your identity provider does not remove them from n8n; they stay logged in until you delete them in n8n manually. You can also exempt specific users from SAML with “Allow Manual Login”. Enabling and configuring SAML or OIDC requires an instance Owner or Admin.

The single sentence to leave with: in n8n, “who can touch this resource” is never answered by an account type alone. It is the account type unioned with the project role, and on the free Community edition most of that machinery is not there at all. Model both axes, check your edition against the table above, and you can answer the question correctly for any user on your instance.