If you run self-hosted n8n and you are about to add a second person to the instance, the question you are really asking is not “Community or Enterprise.” That framing hides the tier that most teams hit first, and it puts the boundary in the wrong place. n8n gates user management across three lines, not one, and the first line is not where people expect it.
The short version: the Community edition is already multi-user and free. What it withholds is collaboration. Leaving Community at all is the first paywall that matters. Single sign-on, granular roles, and an audit trail are a separate, higher cost. And registering the Community edition, the step many operators assume is an upgrade, unlocks zero user management features.
This article is current as of n8n 2.23.4 (the stable release on 2026-06-05; the 2.25.x line is still on the next and beta channels). Feature gates and version numbers move, so the durable thing to take away is the boundary between capabilities, not any single price.
Two axes: account types and role types
Before comparing tiers, separate the two things n8n itself treats as different, because most tier confusion comes from collapsing them.
The first axis is the account type, which is instance-wide. There are three: Owner, Admin, and Member. Every user has exactly one. The Owner sees and can edit everything on the instance. A Member can manage only their own workflows and credentials. The Admin sits between them, with most of the Owner’s reach but without Cloud-dashboard access. See account types for the full permission table.
The second axis is the role type, which is per-project and only exists once projects exist. Within a project there are Admin, Editor, and Viewer roles, plus custom roles on the top tier. A single user can hold different project roles in different projects. See role types.
Account types and role types are independent. A user is one account type instance-wide and can be assigned different role types project by project. Keep that split in mind for everything below. For how the two axes combine into a single user’s effective access, see n8n permissions end to end.
Build with a Member account, not the Owner. n8n’s own docs recommend the Owner create a Member-level account for day-to-day work. The Owner can see and edit all workflows, but there is no record of who created a given workflow, so building as the Owner risks silently overwriting other people’s work and erases authorship. This matters regardless of which tier you are on.
Tier 0: Community edition, free and self-hosted
The Community edition is multi-user. The limit is sharing, not the number of accounts.
You get the Owner account plus Member accounts, and you can invite as many Members as you want at no cost. Per-user two-factor authentication is available with no plan gate; any user can turn on 2FA from their personal settings (2FA docs). What you do not get on Community is the Admin account type, projects, or sharing of any kind.
The practical consequence is the part people miss. On Community, only the instance Owner and the user who created a resource can access that workflow or credential. There is no way to hand a workflow to a colleague for editing, and there are no projects to group work into. Two Community users do not collaborate; they work in isolated silos that only the Owner can see across. The list of excluded features, including Sharing and Projects, is in the community edition features page, which states plainly that only the instance owner and the creator can access a given workflow or credential.
So Community answers “I need more than one login” for free. It does not answer “two people need to work on the same workflow.”
The Registered Community trap
n8n lets you register the Community edition with an email address to receive a free license key. This feels like an upgrade. For user management, it does nothing.
Registering unlocks exactly three things: Folders, Debug in editor, and Custom execution data. None of them touch users, sharing, projects, or roles. If you register expecting shared access or any kind of role control, you will not get it. The full registered-edition list is on the same community edition features page. Treat registration as a workflow-organization perk, not a collaboration step.
Tier 1: the first real paywall, projects and sharing
The moment two people need to work on the same workflow, you leave Community. This is the cost that hits a real team first, well before SSO or audit ever comes up.
Role-based access control and projects are available on every paid plan and on no Community plan. The projects documentation states that RBAC is available on all plans except the Community edition, and that different plans include different numbers of projects and roles. Projects are the mechanism that makes collaboration work: instead of sharing a workflow with a user directly, you add the user to the project that contains the workflow, and everyone in the project sees its workflows according to their role. n8n describes this project-as-sharing model in the sharing docs. Projects scope access inside one instance, not tenancy; for why multi-client work can still need separate instances, see n8n project RBAC vs tenant isolation.
For a self-hoster, the relevant first paid step off Community is the Business plan; on Cloud it is the Starter or Pro plan. Any of these turns on projects and sharing, which is what lets a second person edit a shared workflow. At this tier the baseline project role you can assign is Project Admin, which is enough for real collaboration. The more granular roles climb into higher tiers.
Tier 2: role granularity, Editor, Viewer, and custom roles
Once projects exist, the question becomes how finely you can control what each member does. This is where the built-in roles split across tiers, and the split is not intuitive.
- Project Admin is the baseline project role. Admins manage project settings and members and have full read and write access to the project’s workflows, credentials, and executions.
- Project Editor can create, read, update, delete, and execute everything in the project, but cannot manage members or project settings. The role types page documents the Editor role as available on Pro Cloud and Self-hosted Enterprise plans. It does not list the Self-hosted Business plan for this role, so if you are on Business self-hosted and you need the Editor role specifically, confirm its availability on the pricing page before you plan around it.
- Project Viewer is effectively read-only: it can see workflows, credentials, and executions but cannot edit or even manually execute them. Per the same page, Viewer is available only on Self-hosted Enterprise and Cloud Enterprise plans.
If your requirement is “give an auditor read-only access to a project,” that is an Enterprise-tier cost, not a mid-tier one.
Above the built-in roles sit custom project roles, which let you assemble a role from individual permission scopes such as workflow:execute, credential:read, or project:update. Custom roles are available on Self-hosted Enterprise and Cloud Enterprise plans, and they are recent: available from n8n version 1.122.0 (released 24 November 2025), with secret-vault scopes added in 2.13.0. The scope list is version-dependent, so pull the current catalog from the custom roles page rather than memorizing it. If your governance need is “let this person publish but not delete,” custom roles are the tool, and they are an Enterprise feature.
Tier 3: directory login and single sign-on
Centralized identity is the classic Enterprise line, and it is also the one place where n8n’s documentation and its license enforcement have been reported to disagree.
LDAP lets users sign in with directory credentials. The LDAP docs state it is available on Self-hosted Business and Enterprise, and on Cloud Enterprise. On first sign-in n8n provisions a local account for each LDAP user, and user lifecycle is managed on the directory server, not in n8n.
SAML and OIDC single sign-on are documented the same way. The set up SSO page states SSO is available on Business and Enterprise plans, and both the SAML and OIDC setup guides describe configuring an identity provider through Settings > SSO. You can also configure SSO from environment variables instead of the UI, available from n8n v2.18.0. Role provisioning, where n8n reads a user’s instance role and project access from the IdP at login, was introduced in version 1.122.2 and re-evaluates on every sign-in. For a self-hosted OIDC walkthrough with Google Workspace, Authentik, and Keycloak, plus the PKCE and state limitations, see SSO for self-hosted n8n with OIDC.
The Business-plan SSO contradiction. The docs and the pricing page list SSO under Business and Enterprise, but multiple users on self-hosted Business reported in September 2025 that the SSO settings screen returned “Available on the Enterprise plan” and refused activation even with a valid Business license. See the forum reports here and here. This may have been a licensing-server issue rather than a documented gate, and it may already be resolved, but it has not been confirmed resolved in public. If SSO on self-hosted Business is load-bearing for your plan, verify against your own license before you commit, and do not assume the documented availability matches what the instance enforces.
Tier 3 governance: 2FA enforcement and personal-space controls
Beyond per-user 2FA, n8n has an instance-wide governance layer that is separate from sharing and roles. The Security settings page documents these as available on Business and Enterprise plans, with individual settings showing an Upgrade badge where they require a specific license feature.
Two controls live here. The first is enforced two-factor authentication: an instance-wide toggle that requires every email-and-password user to set up 2FA before continuing. It does not apply to users signing in through SSO, since the IdP owns that path. The second is personal-space policies, which let an admin restrict whether users can share or publish workflows and credentials from their personal space. Disabling sharing affects only new shares; existing shares stay in place.
These are the levers for “lock down what individuals can do on their own” without building full project governance. They are a Business-and-Enterprise capability.
Tier 3 accountability: audit via log streaming
There is no separate “audit log” product in n8n. The who-did-what story is log streaming, which forwards instance events, including a long list of audit events such as logins, credential changes, role-mapping changes, and 2FA-enforcement toggles, to a syslog server, a webhook, or Sentry. Log streaming is available on all Enterprise plans, per the log streaming docs. Self-hosters can manage destinations from environment variables instead of the UI from n8n v2.19.0.
Note the interaction with the earlier Owner warning: log streaming records the events, but if your team builds workflows as the Owner account, authorship is still not attributable at the workflow level. Accountability needs both the audit stream and the discipline of named Member accounts.
Decision matrix: requirement to lowest tier
Map your requirement to the lowest tier that satisfies it. “Off Community” means the first paid plan: Business on self-hosted, or Starter or Pro on Cloud.
| Requirement | Lowest tier that unlocks it | Notes |
|---|---|---|
| More than one user account | Community (free) | Owner plus unlimited Members |
| Per-user two-factor authentication | Community (free) | Each user enables it themselves |
| Folders, debug in editor, custom execution data | Registered Community (free) | No user-management impact |
| Two people editing the same workflow (sharing via projects) | First paid tier off Community | Projects and RBAC turn on here |
| Project Admin role | First paid tier off Community | Baseline project role |
| Project Editor role | Pro Cloud or Self-hosted Enterprise | Docs do not list Self-hosted Business; verify |
| Read-only Project Viewer role | Enterprise (self-hosted or Cloud) | Cannot edit or manually execute |
| Custom project roles with permission scopes | Enterprise (self-hosted or Cloud), n8n 1.122.0+ | Scope list is version-dependent |
| Admin account type | Pro or Enterprise (Cloud naming) | Self-hosted Business not addressed; verify |
| LDAP directory login | Self-hosted Business and Enterprise, Cloud Enterprise | Documented, no reported conflict |
| SAML or OIDC single sign-on | Documented Business and Enterprise | Self-hosted Business enforcement reported as Enterprise-only; verify your license |
| Role provisioning via SSO | Enterprise tier with SSO, n8n 1.122.2+ | Re-evaluated on every login |
| Instance-wide 2FA enforcement; personal-space sharing or publish limits | Business and Enterprise | Security settings page |
| Audit trail via log streaming | Enterprise (all Enterprise plans) | Syslog, webhook, or Sentry |
What this costs, and why the number is not the point
n8n moved to execution-based billing and introduced a self-hosted Business license in its 2025 and 2026 pricing changes, so any figure quoted here would be stale within a quarter, and secondary sources already disagree on the Cloud tier names and prices. The durable fact is the feature boundary, which has been stable: collaboration is the first paywall, granular roles and identity sit higher, and audit sits at the top.
For current numbers and the exact plan names, go to the n8n pricing page. When you do, map your requirement from the matrix above to a tier first, then look at the price for that tier. Pricing the other way around, by budget first, tends to land teams on a plan that is missing the one capability they came for.