Self-Hosted n8n Security: A Production Hardening Guide

A default n8n installation is built for convenience, not for production. The short answer: self-hosted n8n can be made genuinely secure, but only if you work through a specific set of controls in the right order, and some of the controls people assume are free (SSO, external secrets, log streaming) sit behind paid licenses. This guide is the procedure we would hand to any team running n8n on their own infrastructure: what to configure, in what order, what it costs, and where self-hosting is the wrong answer entirely.

Everything below is sourced from the n8n documentation, the n8n pricing page, the project's own GitHub security advisories, and two independent hardening guides. Where the free Community Edition cannot do something, we say so.

Why a default n8n install is exposed

n8n is a credential aggregator by design. Every workflow stores authentication material: API keys, OAuth tokens, database connection strings, SMTP credentials. One instance running 20 workflows might hold the keys to Stripe, your CRM, your production database, and your email provider. As one hardening guide puts it, compromise the instance and you have the keys to all of them, and scanning tools like Shodan index publicly exposed n8n instances regularly (MassiveGRID).

This is not a theoretical risk. The project publishes its own vulnerability record on GitHub Security Advisories, and the pace is worth understanding before you expose an instance to the internet. On a single day, 28 October 2026, the maintainers published ten advisories, including:

• High severity: deprecated Code nodes allowed code execution in the n8n main process, bypassing the isolation that task runners provide (GHSA-9p7v-45m2-wxgj).
• High severity: an insecure GraphicsMagick configuration in image processing (GHSA-f2cw-9483-7vcp).
• Moderate: an OAuth account hijack in the end-user credential connect flow via an unauthenticated callback (GHSA-426f-xmcv-g8pg).
• Moderate: the Browser Use upload tool could read arbitrary files from the n8n server (GHSA-9qx8-fhxv-w794).
• Moderate: credential-using nodes forwarded authentication headers on cross-origin redirects, leaking tokens to third-party hosts (GHSA-prmc-fg87-r4gh).

None of this makes n8n unusually bad. It makes n8n normal: actively developed software with a large attack surface, a responsive security process, and a steady stream of fixes you only benefit from if you patch. The risk profile of a self-hosted instance is mostly determined by two things you control: how you configure it, and how fast you update it.

What is free and what is paid

Before the procedure, the commercial reality, because it shapes the design. The n8n pricing page splits security features across tiers, and the split matters:

• Community Edition (free, self-hosted): user accounts with passwords, per-user two-factor authentication, the n8n audit command, encryption of stored credentials, node blocking, SSRF protection, task runner isolation, execution data pruning and redaction, telemetry opt-out. This is a solid foundation.
• Business (667 EUR per month billed annually, self-hosted available): adds SSO via SAML and LDAP, Git-based version control, and separate environments.
• Enterprise (custom pricing): adds external secret store integration, log streaming, extended data retention, and a support SLA.

Worked example. A 15-person operations team self-hosts n8n Community Edition. Their IT policy says every internal tool must sit behind the company identity provider. That single requirement, SSO, moves them from 0 EUR to 667 EUR per month, roughly 8,000 EUR per year, before infrastructure costs. If the same policy also requires credentials to live in the company vault rather than in n8n's database, they are in Enterprise territory, because external secrets are an Enterprise-only feature supporting AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault, Infisical, and 1Password Connect.

Decide these requirements first. Retrofitting SSO or a secrets vault after workflows and credentials accumulate is much more painful than starting with them.

The hardening procedure

Work through these in order. Each layer assumes the previous one is done.

Step 1: Lock down the network and server

n8n listens on port 5678 by default. That port should never be reachable from the internet. Put a reverse proxy (Caddy, nginx, Traefik) in front that terminates TLS on 443 and forwards internally, then verify from an external machine:

curl -v http://YOUR_SERVER_IP:5678

That command must time out or return connection refused. If it returns an n8n response, your Docker ports mapping or firewall is leaking. In Docker Compose, either give the n8n service no published ports at all or bind it to localhost (127.0.0.1:5678:5678) so the proxy is the only way in (TestedFlows).

On the host itself, the standard baseline applies:

• Firewall: UFW with default deny incoming, allow only 22, 80 and 443.
• SSH: key-based login only, password login disabled.
• OS patches: enable unattended-upgrades so security packages apply automatically.

Set WEBHOOK_URL explicitly to your public HTTPS address, for example WEBHOOK_URL=https://n8n.yourdomain.com/. Without it, n8n generates webhook URLs from the hostname it detects, which behind a proxy often produces unusable http://localhost:5678 addresses. And never set N8N_SECURE_COOKIE=false on a public server; that flag is what stops browsers sending your session cookie over plain HTTP.

Step 2: Set and protect the encryption key

This is the single most important configuration in n8n. Stored credentials are encrypted in the database with a key from N8N_ENCRYPTION_KEY. Generate one before the first start:

openssl rand -hex 32

Three failure modes to avoid, all common:

• Never setting it. If you deployed without this variable, n8n used a default key, which means your credentials are encrypted with a publicly known value. Fix it, then re-enter every credential through the UI so it is re-encrypted.
• Losing it. There is no recovery mechanism. A restored database backup without the key contains credentials nobody can decrypt. Store a copy in your password manager or vault, off the server.
• Scattering it. If you run queue mode, every worker and webhook processor needs the same key to decrypt credentials. Each copy is a place it can leak. Inject it at runtime from a secrets manager, keep it out of Git, workflow exports, and container images, and write down a rotation procedure before you need one.

Step 3: Identity and access

Older guides tell you to set N8N_BASIC_AUTH_USER and N8N_BASIC_AUTH_PASSWORD. That mechanism was removed in n8n 1.0. The current model is user accounts with per-user two-factor authentication:

• Enable 2FA for the owner account first, then every other user, under Settings, Personal. Save the recovery codes in a password manager; they are the only way back in after a lost phone.
• Shorten sessions with N8N_USER_MANAGEMENT_JWT_DURATION_HOURS=2 for internet-facing instances.
• Remove users promptly when they leave; every account is a path to every credential.

If your policy requires SAML or OIDC single sign-on, remember the cost note above: SSO is a Business-tier feature. The Community Edition cannot enforce central offboarding through your IdP, which for some organisations is the deciding factor on its own.

Step 4: Limit what workflows can do

Anyone who can edit a workflow can run code on your server. That makes editor access a security decision, and it makes the sandboxing controls the heart of hardening. n8n's 2.x releases ship safer defaults; check you have not weakened them (TestedFlows):

• NODES_EXCLUDE: the Execute Command and Local File Trigger nodes are disabled by default. Keep them that way unless a workflow genuinely needs them. NODES_EXCLUDE stops n8n loading the node at all; for finer control, node type policies can block nodes per project without a restart (n8n docs).
• N8N_BLOCK_ENV_ACCESS_IN_NODE=true: Code nodes cannot read the server's environment variables, which is where your secrets live.
• N8N_RESTRICT_FILE_ACCESS_TO: limits file nodes to n8n's own directory instead of the whole filesystem.
• Task runners: keep N8N_RUNNERS_ENABLED on so Code node scripts run isolated from the main process. For stronger isolation, n8n documents running task runners as separate sidecar containers in external mode, using the distroless image (no shell, no package manager), running as the unprivileged nobody user, and applying an AppArmor profile so runner containers cannot read /proc files that leak environment variables (n8n docs). Remember the October advisory above: deprecated Code nodes that executed in the main process were a High-severity finding precisely because this isolation matters.

Then close the server-side request forgery hole. The HTTP Request node can be pointed at any address, including your cloud metadata endpoint and internal services. n8n's SSRF protection validates outbound requests from user-controllable nodes against blocked and allowed ranges, and it checks redirect targets and DNS resolution, which defeats DNS rebinding bypasses. Enable it and block internal ranges unless a workflow has a documented need.

Step 5: Authenticate every public entry point

Every webhook you create is a public URL until you restrict it. For production webhooks:

• Require authentication on the webhook node itself: Header auth, Basic auth, or JWT, depending on what the sender supports.
• Validate payloads before acting on them. A webhook that triggers a workflow with unvalidated input is an invitation to fire executions with crafted data.
• If you do not use the n8n public REST API, disable it entirely; the security section of the n8n docs covers the setting.

The advisory list shows why this layer deserves care: the embedded Chat Trigger failed to enforce user authentication on all requests, and the Asana Trigger let an unauthenticated request reset a webhook verification secret. Triggers and webhooks are where the outside world touches your instance.

Step 6: Retention, redaction, and logs

Execution data is a quiet liability. Logs of past runs can contain API responses, customer records, and financial data, and they persist in Postgres until you say otherwise.

• Prune by default: EXECUTIONS_DATA_PRUNE=true with an EXECUTIONS_DATA_MAX_AGE that matches your actual debugging needs. Note the operational catch: pruning frees rows, not disk. Postgres keeps the space until a VACUUM FULL, which locks the table. Set pruning on day one and you avoid the problem.
• Redact where sensitive: n8n can hide input and output data from workflow executions so the editor does not become a browsing tool for production data.
• Stream logs off the box: centralised log streaming is an Enterprise feature. On Community, plan your own log shipping if your auditors expect it.

Step 7: Audit and patch on a cadence

n8n ships a built-in audit. Run it after setup, after every update, and whenever someone new gets access:

docker compose exec n8n n8n audit

It reports credentials not used by any active workflow (delete them; every stored credential is a key someone could misuse), workflows using risky nodes like HTTP Request and Code, and instance-level risks such as an enabled public API or community packages.

Then patching. n8n ships minor releases roughly weekly, and the advisory cadence above shows what falls out of that stream. Read the release notes, back up the database and the encryption key, update a pinned version (never latest), and test the workflows that matter. If you already run separate environments with Git for dev, staging and production, this is where that discipline pays for itself.

Common mistakes

These are the failures we see teams walk into, and all of them are cheap to avoid:

• Setting basic-auth variables from an old tutorial. They do nothing on n8n 1.0 and later. You get user accounts, so use 2FA.
• Exposing 5678 through a Docker ports block while assuming the proxy is the only path in. Run the external curl test; do not assume.
• Changing N8N_ENCRYPTION_KEY after credentials exist. Every stored credential becomes unreadable. Set it before first start, or plan a full credential re-entry.
• Treating the encryption key as an environment detail instead of a secret. In queue mode it is copied to every worker; count those copies.
• Assuming Community Edition has SSO, external secrets, or log streaming. It has none of the three. Discovering this after a compliance review is an expensive surprise.
• Leaving default execution retention on workflows that touch customer data. The editor becomes a read window into everything the workflow has ever processed.

When self-hosting is the wrong choice

Honest limits, because this is a real decision:

• Nobody owns the server. If no one will patch weekly, renew certificates, and test restores, n8n Cloud or a managed service is the safer option. An unmaintained hardened instance becomes an unhardened one within months.
• You need attestations, not controls. If your customers or regulator ask for SOC 2 reports and vendor SLAs for the automation layer itself, self-hosting moves that burden onto you. The Enterprise tier with its support SLA exists partly for this reason.
• Your scale does not justify it. If you run a handful of low-risk workflows, the Starter and Pro cloud tiers (20 and 50 EUR per month) buy you patching, TLS, and backups for less than the engineering time a hardened self-hosted setup costs. Our n8n vs Zapier vs Make comparison covers the broader platform trade-offs if you are still choosing.
• The security requirements are organisational, not technical. Central IdP offboarding, vault-managed secrets, and audit-grade log streaming are all paid features. Price them honestly before concluding that the free edition is free.

For a broader view of where agent and workflow security is heading, our posts on enterprise AI agent security requirements and AI agent security as a cybersecurity challenge frame the same controls at the platform level.

Frequently asked questions

Is self-hosted n8n secure enough for production? Yes, if you do the work: HTTPS through a reverse proxy, a private port 5678, a real encryption key, 2FA on every account, SSRF protection, task runner isolation, authenticated webhooks, and weekly patching. The defaults are built for convenience; the controls above are what make it production-grade.

Do I need to pay for n8n to get SSO? Yes. SAML and LDAP single sign-on are Business-tier features at 667 EUR per month billed annually, and external secret stores plus log streaming require Enterprise. The free Community Edition covers 2FA, audits, encryption, and sandboxing, but not IdP integration.

What happens if I lose the n8n encryption key? Every credential stored in the database becomes permanently undecryptable, including after a successful backup restore. There is no recovery path. Store the key in a secrets manager or password manager, off the server, from day one.

How do I check my instance for problems right now? Run docker compose exec n8n n8n audit from your Compose directory. It flags unused credentials, workflows using risky nodes, and instance-level settings like an open public API. Then run curl -v http://YOUR_SERVER_IP:5678 from outside your network; it must fail.

How often should I update n8n? Minor releases arrive roughly weekly and the project published ten security advisories on a single day in late October 2026. A weekly review of release notes, with updates applied to a pinned version after a backup, is the minimum sensible cadence for an internet-facing instance.

Does n8n Cloud remove these risks? It removes the ones you operate (patching, TLS, server access) but not the ones you design (webhook authentication, credential hygiene, who can edit workflows). It also changes the data residency picture, which matters if your workflows touch data that must stay in your jurisdiction.

Where to go from here

If you are hardening an existing instance, start with the two commands in the FAQ: the built-in audit and the external port check. They take ten minutes and tell you where you stand. If you would rather hand the whole thing off, our business automation service designs, deploys and maintains n8n environments, and our managed open-source stack covers the surrounding tooling when n8n is one piece of a larger self-hosted setup. For organisations with formal governance requirements, our enterprise AI practice handles the documentation and controls side.