Migrating n8n production workloads from community to official Helm charts on EKS

Brief written by the FOSSWire AI editor from CNCF How we write

October 16, 2026 1 min read

Key Takeaway

A case study details the migration of n8n from a community-maintained Helm chart to an official one on Amazon EKS by decoupling application state from local pod storage.

Summary

Fairwinds published a guide on migrating n8n from a community Helm chart to the official version while running on Amazon EKS. The migration required a full cutover because the official chart uses a Deployment model with a single shared PVC, whereas the community chart used a StatefulSet. By offloading state to PostgreSQL, Redis, S3, and AWS Secrets Manager, the team successfully migrated without losing workflow history or data.

Technical migration details

Architecture: n8n was run in queue mode with dedicated worker instances and webhook processors.
State Management: Application state was externalized to PostgreSQL (workflows), Redis (queues), S3 (binary files), and AWS Secrets Manager (encryption keys).
Secret Syncing: Used External Secrets Operator (ESO) to sync AWS Secrets Manager credentials into Kubernetes Secrets.
Migration Strategy: Because the official chart's Deployment model was incompatible with the previous StatefulSet/EBS RWO configuration, the team performed a full cutover rather than an in-place upgrade.
Persistence: Main pod persistence was disabled in the official chart since all critical data resided in external services.

Why it matters

Provides a blueprint for engineering teams running complex automation and AI workloads (like RAG pipelines) using n8n in production Kubernetes environments.

Original reference: www.cncf.io →