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

> **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.

**Published:** 2026-10-16T16:39:04+00:00 
**Source:** Cloud Native Computing Foundation (CNCF) 
**Category:** cloud-native 
**Canonical URL:** https://fosswire.org/news/migrating-n8n-production-workloads-from-community-to-officia.html 

## 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.