n8n network security: checks before restricting access

By Roman Rodomansky·Published 22 Oct 2026

An n8n network security checklist for preserving required webhooks, API calls, DNS and queue-mode dependencies while verifying access restrictions.

• Self-hosting
• Production readiness
• Network security
• Checklist

Checked against the cited sources on 22 Oct 2026.

Checklist: map n8n network security dependencies

Before changing n8n network security rules, record which connections your self-hosted deployment needs. n8n identifies infrastructure firewalls, security groups and network policies as the primary network defense. We think a reviewed connection inventory is a better starting point than a copied ruleset.

This is an editorial verification checklist, not a compliance standard, complete firewall ruleset or deployment tutorial. Exact ports, selectors, destinations and proxy routing must come from your deployment. Start in an isolated practice deployment matching production versions and topology; use the following suggested checks to define completion.

• Record the installed n8n version, deployment topology and Helm chart release where applicable.
• Inventory required ingress callers, outbound API destinations, DNS, database and Redis paths.
• Review dedicated webhook processors, task runners, optional storage and multi-main connections separately if present.
• Give each proposed restriction an owner, expected result, observed result and rollback action.

Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/security/enable-ssrf-protection.md at main · n8n-io/n8n-docs · GitHub

Checklist: preserve webhook ingress through the proxy

n8n assigns self-hosters responsibility for TLS through a reverse proxy. Its reverse-proxy documentation uses N8N_WEBHOOK_URL for the public webhook address; WEBHOOK_URL is deprecated from n8n 2.35.0. Check your installed version before changing an older deployment.

The documented proxy arrangement specifies N8N_PROXY_HOPS=1 and the headers X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto. That hop count is specific to the documented arrangement. Use these suggested checks to close the ingress review.

• Verify TLS handling and the externally advertised webhook address.
• Match proxy hop configuration and forwarded headers to the deployed proxy chain.
• Send a representative required webhook through the restricted public route and confirm the intended workflow executes.

Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/configure-webhook-urls-with-reverse-proxy.md at main · n8n-io/n8n-docs · GitHub, Security

Checklist: retain queue-mode infrastructure connections

The official n8n Helm chart documentation says queue mode requires external PostgreSQL and Redis. It describes workers consuming Redis jobs rather than receiving inbound workflow HTTP traffic. The cited documentation covers an evolving release: main describes chart 2.0 as a release candidate, while chart 1.x installs n8n 2.x. Match these statements to your installed chart release.

For that documented chart, worker readiness depends on database, migration and Redis connectivity. A readiness failure is a troubleshooting signal, not proof of a firewall problem. The following suggested checks connect dependency access to an observable execution.

• Preserve required PostgreSQL and Redis connections for the installed topology.
• Review worker health-check access separately from workflow ingress.
• Run a representative webhook-triggered job and confirm worker execution and healthy readiness.

Sources: n8n-hosting/charts/n8n/README.md at main · n8n-io/n8n-hosting · GitHub

Checklist: restrict egress and review SSRF exceptions

For self-hosted n8n, SSRF protection is available from version 2.12.0. In that documented feature, hostname allowlists bypass IP blocklist checks. This describes application behavior, not infrastructure firewall behavior.

In our view, hostname exceptions deserve the same scrutiny as new outbound permissions. For n8n network security, review the actual application configuration alongside infrastructure restrictions, using these suggested checks.

• Confirm whether the deployed version supports SSRF protection and inspect whether it is enabled.
• Review each hostname exception against a required integration and named owner.
• Exercise representative required API destinations under the proposed restrictions.

Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/security/enable-ssrf-protection.md at main · n8n-io/n8n-docs · GitHub

Checklist: verify Kubernetes enforcement and DNS

Kubernetes implements NetworkPolicy through a supporting network plugin. Applicable policies combine permissions additively, so a new restrictive policy does not cancel broader permissions from another policy. Default-deny egress also blocks DNS.

For Kubernetes deployments, completion means observing the intended permissions in practice. These suggested checks focus on enforcement and the deployment's actual name-resolution path.

• Verify that the installed network plugin enforces NetworkPolicy.
• Inspect every policy selecting the n8n pods for overlapping permissions.
• Identify required DNS destinations and verify name resolution under the proposed egress policy.

Sources: Network Policies | Kubernetes

Checklist: test allowed and denied paths before rollout

In his April 2026 community article, Nathan Berg recommends attempting an unapproved outbound request and verifying that it is denied and logged. This is community guidance, not a mandatory standard or evidence of measured security outcomes.

We'd treat observed behavior as the completion criterion for an n8n network security change. The following suggested checks create a reviewable rollout decision.

• Confirm the required ingress, API and infrastructure tests pass.
• Attempt a deliberately prohibited destination and retain evidence of denial and any expected log entry.
• Compare expected and observed results, resolving unexplained differences before rollout.

Sources: n8n Egress Controls for Security Automation | Nathan Berg