n8n on Kubernetes: Helm Chart, Queue Mode, and When It Pays Off

n8n can usually be run with Docker Compose on a single server within a few minutes, and for the vast majority of small and medium-sized businesses this approach is completely sufficient. Kubernetes with the official Helm chart only becomes relevant once workflows need to be distributed across multiple nodes, scaled automatically, or restarted automatically after failures, for example with very high webhook volume or when a Kubernetes platform is already running in the company for other applications. The official chart is maintained by n8n itself in the repository n8n-io/n8n-hosting and published via an OCI registry. According to the chart README it supports two operating modes: a standalone mode with SQLite and no external dependencies, and a queue mode that requires PostgreSQL and Redis and distributes workload across separate worker pods. As of: August 2026.

What Does the Official n8n Helm Chart Actually Cover?

The chart installs n8n via the helm install command using the OCI reference oci://ghcr.io/n8n-io/n8n-helm-chart/n8n and a custom values.yaml file for configuration. According to the documentation, Helm 3.12 or higher and a Kubernetes cluster running version 1.25 or higher are required. In queue mode, which is the chart's default setting, the architecture distinguishes three pod types: main pods for the UI, API, and non-production webhooks, worker pods that process workflows from the Redis queue and typically run in multiple replicas, and optional dedicated webhook pods for production webhook traffic. The chart also brings support for horizontal autoscaling via HPA and KEDA, for both workers and webhook processors.

How Are Queue Mode and Redis Related?

Queue mode is the prerequisite for multiple n8n workers to process workflows in parallel, and for that n8n needs Redis as a queue. Without queue mode, a single n8n instance processes workflows sequentially in the same process that also serves the UI, which is unproblematic with few workflows but becomes a bottleneck under high load. With queue mode enabled, n8n places workflows to be executed into a Redis queue, from which the worker pods pick them up and process them independently of one another. According to the hosting repository, Redis version 7 or higher is recommended for production use, while version 6 is the minimum required as soon as a Redis username is configured. PostgreSQL is added as the primary database in this setup, since SQLite is not supported for queue mode.

What Prerequisites and Effort Should You Realistically Plan For?

Anyone running the Helm chart in production needs, besides a running Kubernetes cluster, experience operating PostgreSQL, Redis, and ingress configuration, since the chart handles the orchestration of the n8n components but not the operation of the external dependencies. According to the chart documentation, multiple main instances for high availability additionally require an enterprise license as well as session-based load balancing at the load balancer level. For isolating code execution, the chart offers so-called task runners as separate sidecars, which require their own authentication. In practice, this means: the operational overhead compared to a Docker Compose installation is noticeable, from cluster maintenance to monitoring to backup strategies for Redis and PostgreSQL. For an SMB with a handful of automations that can afford to sit in the queue for a few extra seconds, this is usually overkill. The effort makes sense above all when IT teams already bring Kubernetes expertise or when n8n becomes part of a larger platform that is already run on Kubernetes anyway. Anyone unsure which hosting model fits their own automation load should clarify this question before implementation, for example as part of n8n consulting, rather than dealing with oversized infrastructure after the fact. A look at the ROI calculator also helps assess whether the additional operational effort of a Kubernetes solution is proportionate to the expected automation benefit.

Frequently Asked Questions About n8n on Kubernetes

Do I Absolutely Need Kubernetes for n8n?

No, for most SMBs a Docker Compose installation on a single server is completely sufficient. Kubernetes only becomes relevant once scaling across multiple nodes, automatic failover, or an already existing Kubernetes platform in the company come into play. For getting started or smaller automation projects, the operational overhead of a cluster is usually not justified.

Do I Absolutely Have to Use Queue Mode with the Helm Chart?

No, the official chart also supports a standalone mode with SQLite and without external dependencies such as Redis or PostgreSQL. Queue mode only pays off once multiple workers need to process workflows in parallel, because that's when a Redis queue takes over the distribution. For a single, manageable volume of workflows, standalone mode is significantly simpler to operate.

Which Kubernetes Version Do I Need for the Official Chart?

According to the README of the official chart, at least Helm 3.12 and Kubernetes 1.25 are required. Older cluster versions are not officially supported by the chart, so a cluster upgrade should be checked before installation. These minimum requirements may change with future chart versions.

Is the Official Chart Suitable for Production Use or Only for Testing?

The chart is designed for production use and brings features such as horizontal autoscaling via HPA and KEDA, as well as dedicated webhook pods for production traffic. However, the prerequisite is that the external dependencies such as PostgreSQL and Redis are themselves operated in a production-ready manner; the chart only handles the orchestration of n8n itself. Anyone who doesn't have this operational experience in-house should realistically assess the effort before making a decision.