n8n Self-Hosting Security: Environment Variables & Hardening

Securing a self‑hosted n8n instance requires configuring environment variables, enforcing HTTPS via a reverse proxy, restricting network access with firewall rules, enabling Basic Auth, and limiting node execution isolation. Without these measures, a publicly exposed n8n server becomes discoverable within hours and vulnerable to credential exfiltration as well as command injection. Version 2.0 onwards ships with most potentially dangerous capabilities disabled by default, but explicit hardening remains essential for production workloads. [1]

How do you harden a Docker‑based n8n deployment through environment variables?

Set N8N_HOST, N8N_PROTOCOL=https, and a unique N8N_ENCRYPTION_KEY in your docker‑compose.yml or .env file. Exclude high‑risk nodes with NODES_EXCLUDE=["n8n-nodes-base.executeCommand","n8n-nodes-base.localFileTrigger"]. Enable N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=true to prevent the Code node from reading configuration files, and restrict file system operations to a specific directory using N8N_RESTRICT_FILE_ACCESS_TO=/allowed/path. [3]

Containerization itself provides a layer of isolation—mount data as named volumes rather than bind mounts, bind the internal port to 127.0.0.1:5678:5678 to prevent direct external access, and pin the Docker image tag (e.g. n8nio/n8n:1.116.2) for reproducible deployments. [4] For further credential hardening, see our n8n credential security guide.

How do you enforce HTTPS for n8n using Nginx or Caddy as a reverse proxy?

Use Nginx or Caddy as a reverse proxy. In /etc/nginx/sites-available/n8n, define a server block listening on port 443 with proxy_pass http://localhost:5678/. Add proxy_set_header directives to forward the real client IP and protocol, and set proxy_read_timeout 3600 for long‑running workflows. Obtain a free trusted certificate with certbot and Let’s Encrypt. [5]

The critical environment variable is N8N_PROXY_HOPS=1—it tells n8n to trust the proxy headers from Nginx and correctly construct X-Forwarded-For and X-Forwarded-Proto. Without it, webhook URLs may use http:// instead of https://, breaking integrations. [5] For full TLS/SSL setup details, visit the n8n architecture & scaling guide.

What firewall rules should you apply to a self‑hosted n8n server?

Use ufw allow 443/tcp and ufw allow 80/tcp to expose only HTTPS and HTTP ports, keeping port 5678 visible only to localhost. Bind n8n to the loopback interface with N8N_HOST=127.0.0.1 so that all external traffic must pass through your reverse proxy rather than connecting directly to the n8n container. [6]

At the OS level, use iptables or nftables to restrict egress from the n8n container entirely—only allow access to specific destination IPs or domains. This prevents a compromised workflow from exfiltrating data to external servers. For advanced network isolation, see webhook security & IP allowlisting.

How does N8N_BASIC_AUTH protect the n8n editor and REST API?

Setting N8N_BASIC_AUTH_ACTIVE=true, N8N_BASIC_AUTH_USER, and N8N_BASIC_AUTH_PASSWORD prompts a browser authentication dialog for any request to the n8n editor UI or REST API. It does not protect webhook endpoints—webhooks remain public—but it prevents unauthorized users from browsing, editing, or exporting workflows, or reading credential names. [7]

Basic Auth is only a minimum security baseline for exposing n8n over the internet. Always combine it with HTTPS, because credentials are transmitted in cleartext on every request. For multi‑user deployments, n8n’s role‑based access control (RBAC) supports more granular permissions via LDAP or SAML integration. Learn more in the credential security guide.

How does n8n v2.0 isolate code execution for security hardening?

n8n v2.0 runs the Task Runner in external mode by default: every Code node executes in an isolated sidecar container with restricted access to the main process’s file system and environment variables. The Code node can no longer access process.env unless explicitly enabled by N8N_BLOCK_ENV_ACCESS_IN_NODE=false. [1] ExecuteCommand and LocalFileTrigger nodes are disabled by default and must be explicitly whitelisted via NODES_EXCLUDE.

For existing v1.x instances, use the NODES_EXCLUDE environment variable to exclude any node that allows command execution or file access. Additionally, set N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=true to prevent the Code node from reading configuration files in the .n8n directory and restrict the HTTP node from accessing internal IP addresses. For a complete sandboxing strategy, review the execution engine architecture in queue mode.

How do you audit and monitor self‑hosted n8n for security incidents?

Enable API logging in n8n and generate an API key from the Settings panel. Build an audit workflow that queries the REST API weekly for execution history, filters for failed or anomalous runs, and sends a summary to a designated Slack channel. Persist logs to a PostgreSQL database for deeper analysis. [9]

Set N8N_LOG_LEVEL=debug and combine with an external log aggregator like Loki or ELK for real‑time monitoring and anomaly detection. For compliance audits, configure database encryption, maintain backup logs, and use community compliance templates to automate ISO 27001 or SOC2 control validation. [9] For complete alerting and incident response flows, see DevOps alerting & incident response.