FOSSWire
cloud-native

Migrating n8n from community to official Helm charts on Amazon EKS

Brief written by the FOSSWire AI editor from Cloud Native Computing Foundation (CNCF)

1 min read Impact: 4/10

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.

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.

Original reference: www.cncf.io →