Self-Host n8n on Kubernetes

n8n is a fair-code workflow automation tool. Self-hosting it on Kubernetes gives you queue mode across multiple worker pods, which is the part Docker Compose setups usually leave on the table. This page covers what n8n needs to run, what resources to budget, and how worker scaling works. Edka installs the official n8n Helm chart and wires the dependencies for you, on a cluster in your own cloud account.

What n8n Needs to Run

A production n8n install has three dependencies beyond the application itself:

• PostgreSQL. n8n defaults to SQLite, which cannot be shared across pods. Queue mode requires Postgres so the main pod and workers read the same execution history and credentials.
• Valkey or Redis. Queue mode uses it as the job broker between the main pod and workers. Without it, n8n runs single instance and executions block each other.
• A persistent volume. The n8n home directory holds binary data and local files across restarts.

Edka connects n8n to an existing PostgreSQL and Valkey installation on your cluster rather than running a second copy of each per app.

Resource Requirements

Edka’s defaults, applied per pod:

Pod	CPU request	Memory request	CPU limit	Memory limit
Main	200m	512Mi	1000m	1Gi
Worker (2 by default)	200m	512Mi	1000m	1Gi
Task runner sidecar	100m	256Mi	500m	512Mi

At defaults, n8n requests 600m CPU and 1.5Gi memory before task runners. Persistent storage defaults to 10Gi on hcloud-volumes.

That fits a CPX21 node (3 vCPU, 4GB) if n8n is the only workload, though PostgreSQL and Valkey need their own headroom. A CPX31 (4 vCPU, 8GB) is the more comfortable floor once the databases share the cluster. See the Hetzner instance types table for the full range.

Queue Mode and Worker Scaling

In queue mode the main pod handles the editor UI, webhooks, and scheduling. It does not execute workflows. Worker pods pull jobs from Valkey and run them, so throughput scales with pod count instead of with a single container’s CPU.

Two settings control capacity:

• Worker replicas (default 2, range 1 to 20). More pods means more parallel executions and survives a node failure.
• Worker concurrency (default 10, range 1 to 50). Jobs each worker runs at once. Raise it for workflows that mostly wait on HTTP calls. Lower it for workflows that do heavy data transforms in the Code node.

Start at 2 workers with concurrency 10. That is 20 concurrent executions. Watch the queue depth and Node.js heap metrics in the Edka dashboard before adding pods.

Task runners execute Code node JavaScript and Python in a separate process from the worker. This keeps a runaway script from taking down the pod that scheduled it.

Self-Hosting n8n vs n8n Cloud

Self-hosting makes sense when:

• Workflows touch data that cannot leave your infrastructure.
• Execution volume makes per-execution pricing expensive.
• You need workflows to reach services on a private network, which Edka exposes through Tailscale or a Gateway traffic class.
• You want to pin the n8n version and control when it changes.

n8n Cloud is the better answer if you run a handful of workflows and do not want to operate PostgreSQL. Self-hosting means you own the database backups and the upgrade path.

What Edka Provisions

Edka deploys the official n8n Helm chart and configures it for queue mode from the start:

• Queue mode enabled. The main pod is separated from worker pods so executions scale horizontally.
• Worker pods. Dedicated queue workers with configurable concurrency.
• Task runners. Official task runner sidecars run code tasks in isolation, including the native Python runner.
• External PostgreSQL. n8n connects to an existing PostgreSQL installation on your cluster for durable storage.
• Valkey queue backend. An existing Valkey installation coordinates jobs between the main pod and workers.
• Persistent storage. A volume for the n8n home directory on your chosen storage class.
• Prometheus metrics. Queue, workflow execution, and Node.js runtime metrics are exposed on /metrics and wired into the Edka dashboard.
• Encryption key. A stable secret key encrypts stored credentials for the lifetime of the instance.

Configuration Options

• General. Chart version, image tag, encryption key, and optional auto-updates with a patch, minor, major, or custom version policy.
• Database. PostgreSQL installation, database, and user, with optional SSL/TLS verification.
• Queue. Valkey installation, worker replicas, and worker concurrency.
• Storage. Home volume size and storage class.
• Task runners. Toggle runner sidecars and manage the shared authentication token.
• Resources. CPU and memory requests and limits, set independently for the main pod, workers, and runners.
• Placement. Pin pods to a node pool, with automatic tolerations for node pool taints.
• Access. Expose the editor and webhooks through an Envoy Gateway traffic class on your own hostname.

Deploy n8n

1. Click “Deploy n8n” below.
2. Select the target cluster and namespace.
3. Choose your existing PostgreSQL and Valkey installations.
4. Set worker replicas, concurrency, and resource limits.
5. Optionally enable Gateway access on your own hostname.
6. Deploy. n8n runs on your cluster with kubectl access to every component.

Deploy n8n