Skip to content

feat(chart): add hostAliases support to main, worker, and webhook-processor pods - #167

Open
Vishesh-Gupta wants to merge 1 commit into
n8n-io:mainfrom
Vishesh-Gupta:feat/host-aliases-support
Open

feat(chart): add hostAliases support to main, worker, and webhook-processor pods#167
Vishesh-Gupta wants to merge 1 commit into
n8n-io:mainfrom
Vishesh-Gupta:feat/host-aliases-support

Conversation

@Vishesh-Gupta

@Vishesh-Gupta Vishesh-Gupta commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds an optional hostAliases values.yaml key that's templated into /etc/hosts on all three pod types (main, worker, webhook-processor), following the same {{- with .Values.X }} pattern already used for nodeSelector/tolerations/affinity.

Motivation

When self-hosting n8n behind a tunnel/reverse-proxy setup (e.g. Cloudflare Tunnel, or a private-network SaaS connector), n8n's own outbound requests to its own public hostname (N8N_HOST/WEBHOOK_URL) — for example the MCP OAuth server's discovery/token endpoints, which n8n's own OAuth client and third-party MCP clients hit at that public FQDN — have to leave the cluster/VPC and hairpin back in through the external ingress path. This can break in setups where:

  • The tunnel/proxy actively disallows loopback ("hairpin") traffic, or
  • The client hitting WEBHOOK_URL needs a same-Host-header request served entirely inside the private network for latency/security reasons.

hostAliases lets operators pin the pod's own public hostname directly to an internal ClusterIP/private IP so this traffic never leaves the cluster, without needing external DNS changes.

Changes

  • charts/n8n/templates/deployment-main.yaml, deployment-worker.yaml, deployment-webhook-processor.yaml: render spec.hostAliases from .Values.hostAliases when set (no-op otherwise).
  • charts/n8n/values.yaml: new hostAliases: [] default with documentation comment and example.
  • charts/n8n/values.schema.json: schema for the new key.

Test plan

  • helm lint charts/n8n passes.
  • helm template with hostAliases set renders correctly on main, worker (queue mode), and webhook-processor pods.
  • helm template with default values (no hostAliases) produces no hostAliases key in any pod spec — fully backward compatible.

Summary by cubic

Adds optional hostAliases to the Helm chart to inject /etc/hosts entries for the main, worker, and webhook-processor pods. This lets pods resolve n8n’s public hostname to an internal IP to avoid hairpinning through external ingress or tunnels.

  • New Features
    • Adds .Values.hostAliases (default [], schema-validated) with docs in values.yaml.
    • Renders spec.hostAliases in all three deployments when set; no-op when unset.

Written for commit c3ef66d. Summary will update on new commits.

Review in cubic

…cessor pods

Adds an optional hostAliases values.yaml key that gets templated into
/etc/hosts on all three pod types. This is useful for self-hosted
deployments where n8n's own OAuth/MCP clients (or other outbound
requests) target n8n's own public hostname (N8N_HOST/WEBHOOK_URL) and
would otherwise hairpin out through an external load balancer or
tunnel and back in, which can break in restrictive network setups.
@Vishesh-Gupta
Vishesh-Gupta force-pushed the feat/host-aliases-support branch from 84a3023 to c3ef66d Compare July 7, 2026 17:02
@Vishesh-Gupta

Copy link
Copy Markdown
Contributor Author

@krider2010 can someone review this? I believe this would be a good addition

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant