Securing a self‑hosted n8n instance demands layered hardening across six dimensions: authentication, code execution isolation, file‑access restrictions, network‑layer controls, container‑level configurations, and audit monitoring. n8n 2.0 locked down defaults that were previously permissive—Code nodes can no longer access process.env, ExecuteCommand and LocalFileTrigger nodes are disabled by default, and Task Runners now provide process‑level isolation for code execution [1]. This guide provides the definitive hardening blueprint used by production teams.

How do you enable Basic Auth as the minimum authentication layer for n8n?

Set three environment variables: N8N_BASIC_AUTH_ACTIVE=true, N8N_BASIC_AUTH_USER=admin, and N8N_BASIC_AUTH_PASSWORD=your-secure-password. After restart, any request to the n8n editor UI or REST API prompts a browser authentication dialog. This is the recommended minimum security baseline before exposing n8n to the internet, and it is lightweight enough that it does not interfere with workflows or webhook operations. [5]

Basic Auth protects the editor and API only—it does not secure webhook endpoints. Webhooks stay public so external services (Stripe, Slack, GitHub) can call them; you must secure webhooks separately using HMAC signatures, API keys, or custom validation logic inside the workflow [5]. Always combine Basic Auth with HTTPS (via Nginx or Caddy) because credentials are transmitted with every request. For Docker deployments, these variables go in the .env file or directly in the docker-compose.yml. Never commit Basic Auth credentials to git; store them in a secrets manager or environment file excluded from version control. For the complete webhook security hardening guide, see the n8n Webhook Node Security guide.

How do Task Runners and NODES_EXCLUDE prevent Code‑node sandbox escapes?

Task Runners provide process‑level isolation for Code nodes. In internal mode (default), the Task Runner runs as a separate Node.js process spawned by the main n8n process—providing some isolation but still on the same host. In external mode, the Task Runner runs in a dedicated sidecar container using the separate n8nio/runners Docker image, completely isolated from the main n8n process [6].

For defense‑in‑depth, combine Task Runners with NODES_EXCLUDE to block high‑risk nodes entirely. The critical configuration pattern: NODES_EXCLUDE=["n8n-nodes-base.executeCommand","n8n-nodes-base.localFileTrigger","n8n-nodes-base.code"] disables shell execution, arbitrary file access, and the Code node respectively. If you must keep Code nodes enabled, at minimum set N8N_RUNNERS_ENABLED=true with N8N_RUNNERS_MODE=external so Python/JavaScript code executes in the isolated sidecar [6]. Four 2026 CVEs exploited Pyodide or internal‑mode sandbox escapes to achieve remote code execution; all were mitigated by upgrading and switching to external Task Runners. For the complete CVE mitigation strategy, see the Webhook Node Security guide.

How do you restrict file access and environment variable exposure in Code nodes?

n8n 2.0 locked down file access by default: workflows can only access ~/.n8n-files unless N8N_RESTRICT_FILE_ACCESS_TO explicitly allows another directory. Set this to a dedicated, empty directory containing no sensitive data. Keep N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=true (the default) to block Code nodes from reading the .n8n config directory where encryption keys and credentials are stored [7].

Setting N8N_BLOCK_ENV_ACCESS_IN_NODE=true (default in v2.0) prevents Code nodes from accessing process.env—a critical security win that stops workflows from reading database passwords, SMTP credentials, encryption keys, and cloud provider keys [4]. If a workflow genuinely needs an environment variable value, pass it explicitly as an input parameter: add a Set node before the Code node that reads $env:MY_API_KEY and passes it as a JSON field. This pattern keeps control in your hands and never exposes environment variables to the Code node. For database password protection, use the _FILE suffix notation—Docker Compose mounts a secrets file, and n8n reads the password from the file rather than from an environment variable [8]. For the complete environment variable and secrets management guide, see the n8n Credential Nodes guide.

How do you configure Nginx or Caddy as a reverse proxy for HTTPS and secure WebSocket connections?

A reverse proxy sits between the internet and n8n, terminating HTTPS and forwarding traffic to localhost:5678. For production with Nginx, configure a server block listening on port 443, proxy to http://n8n:5678, and forward four critical headers: Host $host, X-Forwarded-Proto $scheme, X-Forwarded-For $proxy_add_x_forwarded_for, and X-Real-IP $remote_addr [9].

For WebSocket support (required for the n8n editor live‑reload and real‑time execution monitoring), add proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade";. Set proxy_read_timeout 3600s; to prevent timeouts during long‑running workflow executions. Then set N8N_PROXY_HOPS=1 so n8n trusts the proxy headers and correctly constructs webhook URLs with https://. Without this setting, webhook URLs may use http:// and break integrations [1]. For teams who prefer simpler TLS setup, Caddy auto‑negotiates HTTPS with zero configuration beyond reverse_proxy n8n:5678 and automatically handles certificate renewal [10]. For the complete reverse‑proxy configuration blueprint including DDoS protection headers and rate limiting, see the n8n Docker Compose production stack guide.

How do you configure host‑level and container‑level firewall rules for n8n?

Use UFW (Uncomplicated Firewall) at the host level: ufw allow 443/tcp && ufw allow 80/tcp && ufw enable. This opens only HTTPS and HTTP ports—port 5678 must remain closed to external traffic. Bind n8n to the loopback interface with N8N_HOST=127.0.0.1 so n8n only listens on localhost, forcing all external traffic through the reverse proxy [1].

At the container level, enforce egress filtering with iptables or nftables: restrict outbound traffic from the n8n container to only the specific IPs or domains your workflows need. This prevents a compromised workflow from exfiltrating data to arbitrary external servers [11]. The strictest approach blocks all egress by default, then whitelists only approved destinations (Slack webhook URLs, Stripe API endpoints, your database server). For Docker deployments, define the n8n-network as an isolated bridge network with internal: true so only explicitly defined services can communicate, and use service‑level restart: unless-stopped with health checks on all containers. For additional logging, use Docker’s --log-driver=json-file with --log-opt max-size=10m and max-file=3 to prevent disk exhaustion from debug logs [12]. For the production‑ready Docker Compose blueprint that combines all these controls, see the n8n Docker Compose production stack guide.

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

Begin with a workflow content audit: check every Code node for references to process.env, hardcoded API keys, passwords, tokens, or secrets—these should immediately be replaced by credential nodes or input‑parameter passing. Review each HTTP Request node to verify it only calls expected endpoints, and scan for ExecuteCommand or LocalFileTrigger nodes unless they are explicitly required [3].

For operational monitoring, set EXECUTIONS_DATA_SAVE_ON_SUCCESS=all to retain input/output data for successful runs (not just failures), and N8N_LOG_LEVEL=debug for detailed logs [13]. Build a monitoring workflow that queries the n8n REST API for execution history, filters for anomalies (unexpected HTTP status codes, long execution durations, access from unusual IPs), and posts alerts to a dedicated security Slack channel. Combine these logs with an external log aggregator (Loki, ELK, or Datadog) for cross‑instance visibility and real‑time alerting. For compliance audits, maintain the instance at a known version (pin Docker image tags), regularly apply security patches, and follow the WotAI audit checklist—the same checklist used internally by professional automation agencies [3]. For integrating security monitoring with incident response pipelines, see the n8n DevOps Nodes guide.