n8n on EKS: Why the Helm Chart Switch Needed a Full Cutover

A Fairwinds team ran n8n on Amazon EKS for about a year on a community Helm chart, then found that moving to n8n’s official chart couldn’t be done as an in-place upgrade at all. The blocker wasn’t n8n. It was a single gp3 EBS volume that couldn’t attach to more than one pod, and the fix was to prove that the volume held nothing worth keeping. For platform teams now hosting n8n for automation and AI agent workloads, the lesson is to know exactly where your state lives before you change charts.

How It Works

Writing on the CNCF blog, Fairwinds’ Husne Ozmen sums up the gap between demo and production: a single container with SQLite is fine for trying n8n, but production needs workers, webhook processors, PostgreSQL, Redis, object storage, external secrets, ingress routing and an upgrade plan that preserves workflow history. The post notes that n8n is increasingly used for self-hosted agents and RAG pipelines, which put extra pressure on workers, secrets and state handling.

The team ran n8n in queue mode. The main instance manages workflow information and triggers; worker instances execute jobs pulled from a Redis queue; dedicated webhook processors take production webhook traffic. Ingress was split by traffic type, with public webhooks behind an internet-facing load balancer and internal webhooks on a private hostname. PostgreSQL stored workflow and execution data, Redis held queued jobs, and S3 held binary files.

Secrets needed special handling. Because running multiple replicas of the main pod is a licensed Enterprise capability, the team needed a consistent way to share application configuration and the encryption key across pods. They kept secrets in AWS Secrets Manager and synced them into Kubernetes Secrets with External Secrets Operator.

Why the Chart Switch Broke the Upgrade Path

The community chart ran the main pod as a StatefulSet with one persistent volume per replica, which avoided multi-attach errors on ReadWriteOnce gp3 volumes. In the team’s configuration, the official n8n Helm chart ran main as a Deployment backed by a single shared PVC. Their gp3 volume couldn’t attach to main pods on multiple nodes, so a helm upgrade was off the table and the move became a full cutover.

The deciding step was an inventory. PostgreSQL, Redis, S3 and Secrets Manager already held all required state, and the team found nothing on the main pod’s volume that needed to persist. So they disabled main persistence entirely in the official chart. A replacement main pod could start and reconnect without a pod-specific disk.

What This Means for You

The cutover kept the database, queue, object storage, IAM role and secrets in place and recreated everything else from the new chart’s values. Before touching production, the team tested rollback in non-production against a restored database snapshot, took a fresh snapshot, saved secrets to a secondary location, and deliberately did not change the n8n image version, since a version bump could trigger a database migration. Separating the chart change from the app upgrade kept the database out of the cutover. That discipline mirrors the case Stack Archive made on EKS version rollbacks: change one layer at a time, with a tested way back. Ozmen’s sample values repository shows the official-chart setup with external Postgres and Redis, queue mode and HPA.

Source: CNCF Blog

Content created with AI assistance and reviewed for accuracy.