# Migrating n8n from community to official Helm charts on Amazon EKS

> **Key takeaway:** A production migration of n8n on EKS was achieved by decoupling application state from the main pod to allow a switch from community to official Helm charts.

**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-from-community-to-official-helm-charts-on-amaz.html 

## Summary
A technical report details the migration of n8n from a community-maintained Helm chart to the official version on Amazon EKS. To avoid storage conflicts with AWS gp3 volumes, the team moved from a StatefulSet model to a Deployment model by offloading all state to PostgreSQL, Redis, S3, and AWS Secrets Manager. This allowed for a full cutover without losing workflow history or critical data.

## Technical migration details
- **Architecture**: n8n was run in queue mode with dedicated workers and webhook processors.
- **State Management**: All persistent data was externalized to **PostgreSQL** (workflows), **Redis** (queues), **S3** (binary files), and **AWS Secrets Manager** (encryption keys).
- **Workload Change**: The community chart used a **StatefulSet** for main pods to handle RWO volumes, while the official chart uses a **Deployment** with a shared PVC.
- **Secret Handling**: **External Secrets Operator (ESO)** was used to sync AWS Secrets Manager credentials into Kubernetes Secrets.
- **Migration Strategy**: A full cutover was performed instead of an in-place upgrade to resolve the storage model incompatibility.

## Why it matters
The report provides a blueprint for running complex workflow automation tools in production Kubernetes environments using cloud-native patterns.