n8n Security
Your n8n instance holds the keys to every system it automates. Secure it like it.
Why n8n security deserves respect
An n8n instance is a credential concentrator: it stores working tokens for your email, CRM, database, payment provider — everything you've automated. Compromise the instance and every connected system is exposed. Public scans regularly find unauthenticated n8n installs; don't be one of them.
This is the checklist we apply to every deployment we operate. DIY self-hosters: steal it freely.
Access and authentication
- Never expose n8n directly to the internet. Reverse proxy (Traefik/nginx) with TLS in front, always; VPN or IP-allowlist for the editor UI where possible.
- SSO/SAML or at minimum enforced strong auth for every user; n8n Enterprise adds SSO and project-level RBAC (when Enterprise is warranted).
- Least-privilege users — builders don't need owner; viewers don't need edit.
Credentials and secrets
- Set a strong
N8N_ENCRYPTION_KEYand back it up separately from the database — credentials are only as safe as that key. - Prefer external secrets (Vault, cloud KMS) on Enterprise; rotate tokens on a schedule and after any staff change.
- Scope OAuth grants minimally: an agent that reads a calendar doesn't need domain-wide delegation.
Network and webhooks
- Webhook URLs are unauthenticated by default naming — add verification (HMAC signatures, secret path segments, or header tokens) to every production webhook.
- Separate the editor (locked down) from webhook endpoints (public) — n8n supports distinct hosts for a reason.
- Egress-restrict where possible: an instance that can only reach the services it automates limits blast radius.
Operations
- Update discipline — n8n patches security issues in regular releases; a version pinned for a year is an open CVE list. (This is where managed operation quietly earns its fee.)
- Postgres, not SQLite, for production; encrypted backups with restore drills, not just backup cron jobs.
- Audit logging — stream execution and access logs somewhere the instance itself can't erase.
The AI layer
Workflows calling LLMs add two risks classic checklists miss: data egress (what customer data leaves for which model provider — decide per data class, route accordingly: multi-provider strategy) and prompt injection (an email that tells your agent to exfiltrate the inbox — keep irreversible actions behind approval steps, exactly as we argued in the enterprise guide).
The honest summary
None of this is exotic — it's standard web-app hardening applied to a high-value target, plus AI-era egress rules. It's also recurring work, not one setup weekend, which is why security is a standing line in every deployment we operate (hosting options). Running your own and want it reviewed? We do security reviews of existing n8n installs.