n8n security checklist for a shared, self-hosted instance
An n8n security checklist for engineering managers: instance baseline, encryption key hygiene, webhook exposure, user access with rbac examples, and feature limits.
Checked against the n8n documentation on .
What this n8n security checklist covers
This n8n security checklist is written for the moment a self-hosted instance stops being one person's sandbox and becomes shared infrastructure. It covers five areas: the instance baseline, credentials and the encryption key, webhook exposure, user access and roles, and feature restrictions that limit what a workflow can read.
Everything factual here comes from n8n's own product documentation. No benchmark, survey or incident data was supplied, so treat the checks as documented controls rather than measured protection, and confirm plan availability and defaults on your own version before you commit to a rollout plan.
"Done" for each section means the same thing: a named owner has verified the setting on the live instance, written the expected value somewhere your team can find it, and set a date to look again. n8n documents a self-hosting security overview that covers running a security audit, setting up SSL and SSO, restricting nodes and the public API, and redacting execution data, plus two-factor authentication for users.
The audit itself can be run three ways: the command line, the public API authenticated as the instance owner, or the n8n node. Its Instance report flags unprotected webhooks, missing security settings and an outdated instance.
Sources: Security | Deploy | n8n Docs, Run security audits | Deploy | n8n Docs
Instance baseline and encryption key hygiene
Start with transport. For TLS, n8n recommends terminating in front of the instance with a reverse proxy such as Traefik or a network load balancer rather than exposing n8n directly.
Then the encryption key. n8n encrypts credentials with a key that is auto-generated in the .n8n home directory on first launch, and you can override it with the N8N_ENCRYPTION_KEY environment variable. A suggested team standard: set it explicitly and store it in your secret manager, so the key is not something that only exists on one disk. If you run queue mode, the documentation is explicit that the encryption key environment variable must be set for every worker.
Two-factor authentication can be enforced for all users with N8N_MFA_ENFORCED_ENABLED, which defaults to false. Note that when this policy is managed by environment variables, the matching controls in the interface are locked.
Single sign-on with SAML or OIDC is a paid feature: Cloud Enterprise, and Business or Enterprise on self-hosted. Configuring SSO with environment variables is available from n8n 2.18.0; older instances configure it in the interface.
Sources: Security | Deploy | n8n Docs, Set up SSL | Deploy | n8n Docs, Set a custom encryption key | Deploy | n8n Docs, Security | Deploy | n8n Docs, Configure SSO | Deploy | n8n Docs
Webhook exposure checks
Webhooks are where a shared instance leaks first, because a production URL is reachable by anyone who learns it. The Webhook node supports Basic auth, Header auth or JWT auth, and also None, which leaves the URL open. If the IP allowlist field is left blank, any address can invoke the production webhook URL.
| Option | What it checks | Leaves open |
|---|---|---|
| Basic auth | Username and password on the request | Nothing further documented |
| Header auth | A named header value | Nothing further documented |
| JWT auth | A signed token on the request | Nothing further documented |
| None | No caller verification | Anyone with the URL |
| Empty IP allowlist | No source restriction | All IP addresses |
A reasonable team standard, offered as a suggestion rather than a documented requirement: every production webhook gets an authentication method and an allowlist, and both are checked during workflow review alongside naming and error handling. This is the part of n8n security that most often slips when several people publish workflows.
One version-specific behaviour is worth knowing before you upgrade. From n8n 1.103.0, HTML webhook responses are automatically wrapped in sandboxed iframes as a protection mechanism, which can break workflows that relied on the previous behaviour.
Sources: Webhook | Nodes | n8n Docs
User access, roles and rbac examples
Access control in n8n operates at instance level with the built-in Owner, Admin and Member roles, and you can also create custom instance roles. The point of custom roles, per the documentation, is that a user gets only the capabilities they need instead of full Admin access. Custom roles, both instance and project, require Enterprise on Cloud and self-hosted alike, so check the tier before you design around them.
Projects group workflows and credentials together, and project admins add and remove users within their project. Practical rbac examples for a shared instance: new joiners default to Member; a small named group holds Admin; each department gets a project so its credentials are not visible to everyone; and a project admin owns joiner and leaver changes for that project.
One operational trap belongs in your change process. Moving a workflow or credential between projects or users removes all existing sharing and can affect other workflows, so announce moves in advance rather than doing them quietly on a Friday.
If your team keeps n8n workflows in a GitHub repository, a suggested addition to this review: decide who may access that repository at the same time you review instance roles. The supplied n8n documentation does not cover version control, so set that standard yourself.
Sources: Set permissions and roles (RBAC) | Administer | n8n Docs, Organize work in projects | Administer | n8n Docs, Custom roles | Administer | n8n Docs
Feature restrictions and a review cadence
The last layer limits what a workflow can reach even when it runs successfully. N8N_BLOCK_ENV_ACCESS_IN_NODE controls whether users can read environment variables from expressions and the Code node, and defaults can vary by version, so read the value on your instance rather than assuming. The same overview points to restricting nodes and the public API and redacting execution data, which matters most when many people can open someone else's execution history.
Scope your review honestly. No supplied source covers backups, network isolation, external secret managers or log monitoring in depth, so those need their own work outside this list.
A workable cadence, suggested rather than prescribed: run the audit monthly, review roles and project membership when someone joins or leaves, and re-read webhook authentication settings whenever a workflow moves to production. Completion is not a one-off green tick; it is a short recurring pass that someone owns.
A recurring n8n security review pass
- Audit: Run the security audit and read the Instance report.
- Triage: Treat unprotected webhooks and an outdated instance as blocking.
- Access: Review Owner, Admin and project membership against the current team.
- Webhooks: Confirm authentication and IP allowlists on production webhooks.
- Record: Write down expected values and set the next review date.
That recurring pass is what keeps n8n security real rather than aspirational on a shared instance.
Sources: Security | Deploy | n8n Docs, Security | Deploy | n8n Docs
