Users, roles and permissions in self-hosted n8n: collaborating without stepping on each other

As long as you're alone on your n8n instance, permissions are a non-issue: you're the owner, everything belongs to you, all is well. The day a colleague joins in, the concrete problems arrive fast — who changed the invoicing workflow last night? Why does the intern have access to the production CRM's API key? How do you give the marketing team the use of the Slack connection without handing over the token? Self-hosted n8n ships with a system of users, roles and sharing that answers these questions, with some honest limits worth knowing: part of the advanced features is reserved for paid plans. Here's how to structure a multi-user instance cleanly, knowing exactly where that line sits.

The owner account: the instance's first user

On the first launch of a freshly installed instance (see our Docker installation guide), n8n asks you to create the first account: the owner account. It is unique — an instance has only one owner — and it holds the broadest rights: user management, access to instance settings, visibility over resources.

Two practical consequences. First, this account should not be anyone's day-to-day working account: reserve it for administration, protect it with a strong password and two-factor authentication, and do your daily work with a named member account. Second, keep careful track of who holds this account and how to recover it: an owner whose credentials nobody remembers means a database or command-line intervention to regain control.

Inviting members: SMTP or a link to copy

Inviting users happens from the instance settings, in the users section. Two scenarios:

• SMTP configured: n8n automatically sends an invitation email containing the activation link. The configuration is done through environment variables (N8N_SMTP_HOST, N8N_SMTP_PORT, N8N_SMTP_USER, N8N_SMTP_PASS, among others) set in your docker-compose.yml or the container's environment.
• No SMTP: the invitation still works. n8n creates the pending account and displays an invitation link to copy, which you pass along to the newcomer yourself. The link lets them set their password and activate their account.

For a small team, the copied link is more than enough. SMTP becomes worthwhile once invitations are frequent, or to enable password resets by email — without SMTP, a forgotten password gets fixed on the administrator's side.

Global roles: owner, admin, member

n8n distinguishes three role levels at the instance level:

• Owner — the instance's single proprietor, with all rights.
• Admin — extended management capabilities (user management, broad visibility over resources) without being the owner. The availability of this role and the detail of its permissions depend on your n8n plan.
• Member — the default role for any invitee: they create their own workflows and credentials, and only access other people's resources when those are explicitly shared with them.

This structure follows the classic role-based access control (RBAC) model, formalized by Sandhu, Coyne, Feinstein and Youman in "Role-Based Access Control Models" (IEEE Computer, 1996 — see on Google Scholar): rather than assigning permissions one by one to each individual, you assign permission-bearing roles, which makes administration predictable and auditable. That is exactly the philosophy behind n8n's global roles and per-project roles.

One important point of honesty: on the self-hosted Community plan, only count with certainty on the owner/member duo and explicit resource sharing. The admin role, fine-grained RBAC, SSO/SAML and LDAP directory integration belong to paid plans — check what is actually enabled in your own interface for your license before designing your organization around a feature you don't have.

Sharing workflows and credentials between users

By default, each member only sees what they created. Sharing happens resource by resource, and this is where n8n's model becomes genuinely useful.

Workflow sharing. A workflow's creator can share it with other users, who can then view it and, depending on the rights granted, edit it. This is the basic mechanism for shared maintenance: the invoicing workflow no longer belongs to "the person on vacation" but to the team that relies on it.

Credential sharing. This is the most valuable feature of the lot: sharing a credential lets a colleague use it in their workflows without ever seeing the secret. They select "Production CRM" from the list, their calls work, but the API key itself remains invisible and unexportable to them. You thereby separate the use of a connection from the knowledge of its secret — a pattern we detail in our article on securing credentials, and one that changes everything the day someone leaves the team: revoking an access no longer means rotating every key they may have seen.

Projects: isolating teams on a single instance

Beyond individual sharing, n8n offers the notion of a project: a container grouping workflows and credentials, with members and per-project roles (project administrator, editor, viewer, depending on the version). The marketing team works in its project, the finance team in its own, and neither sees the other's resources — isolation is managed at the container level rather than resource by resource.

This is where the plan boundary is felt the most: the ability to create multiple projects, the granularity of per-project roles and advanced RBAC are, for the most part, reserved for n8n's paid plans. If you're on the Community plan and isolation between teams is a genuine need, two pragmatic alternatives exist: separate instances per team (self-hosting makes this option inexpensive, as our analysis of the real cost of self-hosting shows), or separation by environment rather than by role, which is the subject of the next section.

Best practices for a shared instance

Apply the principle of least privilege. Each user should receive only the access strictly required for their task — a principle formulated as early as 1975 by Saltzer and Schroeder in "The Protection of Information in Computer Systems" (Proceedings of the IEEE — see on Google Scholar), and one that hasn't aged a day: the fewer rights an account holds, the less its compromise or its mistakes cost. Concretely: member role by default, explicit shares, and no production credential shared "just to unblock things."

One service credential rather than personal accounts. When a workflow sends emails or posts to Slack, create a dedicated service account ("automation@your-domain") and share that single credential, rather than letting everyone plug in their personal account. When someone leaves, nothing breaks; and the workflows' actions are clearly identifiable as such in the target tools.

Separate dev and prod rather than multiplying roles. Trying to solve everything with permissions on a single instance quickly turns into a Rube Goldberg machine. A development instance where everyone experiments freely, and a locked-down production instance where only one or two accounts deploy, solves 80% of the problem with two roles and zero advanced RBAC. Our guide on dev/prod environments details this architecture.

Track who changes what. Permissions say who can act; you also need to know who did act. Versioning workflows in Git (see our article on versioning workflows with Git) gives you a readable history of changes, with author and date, independently of what your n8n plan logs natively.

Common pitfalls

• Doing daily work with the owner account. Any slip of the hand then happens with maximum rights, and the history no longer distinguishes administration from routine use. Create yourself a named member account by day two.
• Assuming a feature seen in the documentation is included in your plan. Multiple projects, advanced roles, SSO/SAML, LDAP: the n8n documentation describes everything, your license doesn't enable everything. Check your own interface before promising your team any isolation guarantees.
• Bypassing credential sharing by copying keys around. If everyone recreates "their own" credential with the same API key pasted from a Slack channel, you lose the benefit of the masked secret and revocation becomes impossible to track. One credential, one owner, explicit shares.
• Forgetting to deactivate leavers' accounts. An orphaned member account keeps its access and its shares. Add n8n deactivation to your offboarding checklist, right alongside email.
• Multiplying roles to compensate for a missing dev/prod separation. If you catch yourself inventing naming conventions to flag the "do not touch" workflows, that's the sign you need a second instance, not one more role.

Going further

User management is one of the structural differences between self-hosting and the cloud — our self-hosted vs cloud comparison will help you position your needs if you're still hesitating. And because permissions only say who can act, not what the workflows actually do with the data, the Compliance & Audit Pack (€149) naturally complements this access control with an actionable audit trail: processing logs, execution traceability and GDPR compliance, in line with our article on the GDPR audit trail with Supabase. Controlling access to the instance, then tracing what happens on it: two halves of the same requirement.