Learn n8n - Governance & Multi-user Collaboration

#Introduction

In episode 13 you monitored the instance with execution data, Prometheus metrics, and alerts. Now imagine the same instance used by thirteen people from three different teams. Without rules of the game, one person could change a workflow used by others, or read credentials that aren't theirs. Observability doesn't answer that problem — what's needed is governance.

Episode 14 covers Governance & Multi-user Collaboration: managing user access and role-based permissions, sharing workflows, credentials, and folders, as well as maintaining change control and audit trails.

#User Model & Role-Based Permissions

n8n distinguishes access rights on two levels. First, the instance level, with three main roles:

• Owner — holds full control of the instance: manages users, licenses, settings, and all resources. Only one person holds this position.
• Admin — manages users, instance settings, and shared resources without license management rights.
• Member — manages their own workflows and resources; only accesses things shared with them.

Second, the project level. Since version 1.x, n8n introduced projects as a sharing container: each project has its own set of workflows and credentials, and its membership determines who can work inside it. On top of this layer, RBAC gives finer control — for example edit rights are distinguished from view-only rights.

This model follows the least privilege principle: everyone gets the lowest rights sufficient for their task. Owners don't need to edit every daily workflow, and members don't need to touch instance settings. This firm boundary between roles is what prevents "one person deleted everything" incidents.

#Managing User Access

Adding members is done via Settings → Users, then sending an invitation by email. The chosen role determines their working boundaries. To ensure only the right people get in, complete it with:

• MFA — two-factor authentication for accounts, reducing the risk of stolen login credentials.
• SSO — SAML or OAuth2 integration on enterprise licenses so login follows company identity policies.
• CLI provisioning — when bootstrapping an instance, the owner can elevate roles via the command line before the UI is accessed.

Example of promoting the first user to owner during setup, then listing users via the Public API:

n8n user-management:promote --email=owner@example.com

curl -s https://n8n.example.com/api/v1/users \
  -H "X-N8N-API-KEY: n8n_api_xxxxxxxxxxxx"

The Public API can also be used for administration automation — for example scripts that schedule access rotation, or syncing the user list from an HR system. Make sure the API key used for this task is dedicated and given limited rights, following the security patterns we built in episode 12.

The minimal principle: give the lowest role possible, raise it only when needed, and audit role changes periodically. When someone switches teams or leaves the company, refresh their access as soon as possible — forgotten old accounts are a commonly exploited backdoor.

#Sharing Workflows, Credentials & Folders

Sharing in n8n is done per resource, not per instance. Each workflow can be shared:

• To all users — suitable for common workflows like error handlers or notifications.
• To a specific project — workflows are organized in projects, and project members get access according to their roles.

Folders complete the organization: workflows can be grouped into folders within a project, so hundreds of workflows don't pile up in a single list. A recommended structure for teams:

Project: Core-Ops
  ├── Folder: Triggers
  ├── Folder: Sync (database)
  └── Folder: Reports
Project: Marketing
  └── Folder: Campaigns

#Controlling Credential Access

Credentials are the most sensitive asset, so their sharing rules are stricter. When creating a credential, you choose which project is allowed to use it. Members outside the project can't see, let alone use, that credential — even if they open a workflow that references it.

This is important to understand when sharing workflows: a shared workflow keeps running normally using its owner's credentials, but the recipient doesn't automatically get access to the credential values. If needed, the owner shares the credential to another project explicitly. The credential values themselves are never visible to anyone — only their reference.

When should a credential be shared? The rule of thumb: share only when a workflow genuinely uses it, and limit it to the smallest project that needs it. Avoid one giant credential used by all projects — when the service changes, rotating that credential disrupts the entire instance at once.

#Change Control

Shared workflows change quickly; what's dangerous is change without a trace. Two mechanisms guard against this:

• Per-workflow version history — n8n keeps version history, so you can see who changed what and restore a previous version in case of regression.
• Source Control — on licenses that support it, workflow definitions are synced to a Git repository. Every change becomes a documented commit, and workflows move between environments (staging to production) through a review process like regular code.

git checkout -b fix/webhook-timeout
n8n workflow:update 42 --name "Laporan Harian v2"
git add workflows/laporan-harian.json
git commit -m "fix: naikkan timeout webhook laporan harian"
git push origin fix/webhook-timeout

Source control sync only pushes workflow definitions — not credentials. A workflow promoted from staging to production expects an identically named credential to already exist in production with its own values. This is by design so secrets don't travel between environments. The change control principle is simple: the production environment must not be changed directly by anyone, except through a documented flow. CI/CD details for workflows will be discussed in episode 18.

#Audit Trails

The last piece completing governance is the audit log. On enterprise licenses, n8n records important events permanently: user logins, workflow changes, credential creation and updates, user or role changes, as well as source control activity.

The audit trail answers the questions asked during incident investigation: who logged in last, who changed this workflow, when was this credential rotated. Because the records are append-only, this trail can serve as compliance evidence. To align with organizational policy, audit events can also be streamed to a SIEM or integrated with the observability built in episode 13.

#Closing

Episode 14 turned a personal instance into a team platform. You understand the owner, admin, and member role model with the project and RBAC layers on top, how to manage users with MFA and SSO, sharing workflows, credentials, and folders with separate controls, as well as maintaining change control through version history and source control complemented by audit trails.

Key takeaways:

• Layered access rights: instance roles set global boundaries, projects set per-team boundaries.
• Credentials are shared more strictly than workflows — credential values are never visible, only their reference.
• Share per resource, not per instance, using projects and folders as structure.
• Change control uses version history and Git source control, with credentials not synced along.
• Audit trails answer the "who, when, and what" of every important event.

In the next episode we take n8n out of the laptop toward production: Self-hosting & Deployment Patterns — deploying with Docker Compose, Kubernetes, and cloud VMs, choosing storage backends and databases, up to high availability and scaling worker nodes. See you there!