News › linux
By The Linux Camp News, October 18, 2026
A production EKS deployment moved to n8n’s official Helm chart without replacing its external state services. Auditing the main pod’s disk allowed the team to remove a shared-volume attachment dependency.
Fairwinds engineer Husne Ozmen’s CNCF account describes a completed production n8n migration on Amazon EKS from a community Helm chart to n8n’s official chart. This was a change in deployment packaging, not an application release: the team retained its database, queue, object storage, IAM role and secrets. October 16 is the account’s publication date, rather than a documented cutover date. 1
The old storage arrangement matters to understanding the migration. The community chart ran the main component as a StatefulSet, with a separate persistent volume for each replica. Workers and webhook processors already used Deployments. According to Ozmen, the per-replica storage arrangement avoided multi-attach problems with the deployment’s AWS gp3 ReadWriteOnce EBS volumes when running multiple main pods. 1
In the team’s official-chart configuration, main instead ran as a Deployment whose persistence depended on one shared persistent volume claim, or PVC. That changed the attachment requirement: main pods on different nodes would need the same gp3 volume, which could not attach across those nodes. The team therefore chose a full cutover rather than an in-place Helm upgrade. This is a reported configuration incompatibility, not evidence that every official-chart deployment has a storage defect. 1
The solution was to remove unnecessary main-pod persistence, not replace the storage backend. An audit found workflow and execution data in PostgreSQL, queued jobs in Redis, files in S3, and the encryption key and application secrets in Secrets Manager. Nothing required on the main volume needed to survive replacement. Disabling that volume removed the attachment dependency because replacement main pods could reconnect to those external services. 1
For another operator, the inference is conditional: establish where durable data lives before copying this storage decision. The maintainer’s standalone example, retrieved October 18, 2026, stores SQLite data on a PVC, so this case does not justify removing persistence there. Replicating the multi-main topology also has a licensing boundary: n8n’s examples require an Enterprise license and direct Community Edition users to a single main pod. 5 4
The team kept the n8n image version unchanged to avoid combining the chart cutover with a possible database migration. Preparation included a database snapshot, a secondary copy of secrets and rollback testing outside production. With restored data, they checked pod health, completion of known workflows and endpoint reachability. These checks tested application behavior as well as whether Kubernetes could start the replacement workloads. 1
Preserving secrets means preserving their values, especially the encryption key. This deployment synchronized Secrets Manager data into Kubernetes through External Secrets Operator. n8n’s documentation explains why key continuity matters: every stored credential is encrypted with that key, and changing it while switching between environment-variable and file-based key delivery makes those credentials unreadable. 1 2
The linked values repository is an illustration, not a production migration record. Its chart pin of 1.0.0 should not be treated as the version used in the reported cutover. The repository explicitly labels its hostnames and secret names as placeholders and warns that value keys can change between chart versions. It is therefore a configuration reference, not a ready-to-run migration plan. 3