n8n on AWS EKS Without the Production Surprises

Choose, Preserve, Prove. Choose the smallest platform that meets the workload and recovery requirements. Preserve application state across changes: workflows, credentials, the encryption key and any binary data. Prove recovery with a restore test, not a dashboard full of running pods.

Running n8n on AWS EKS is defensible when Kubernetes removes more operational work than it creates. It is not the automatic next step after Docker Compose.

ECS/Fargate can run n8n queue mode with managed PostgreSQL and Redis dependencies. Fargate supplies compute; it is not another name for EKS. AWS documents Fargate support for both ECS and EKS.

For EC2, make the recovery agreement concrete: “We accept up to two hours offline after host loss.” Then demonstrate that recovery, including credential decryption. A backup job succeeding is not the same test.

These are engineering decision rules, not execution-volume thresholds. Cloudline Consulting’s cloud, DevOps and Kubernetes services approach platform assessment around these workload, ownership and recovery constraints—not a predetermined cluster choice.

Diagram 1 — baseline queue deployment: for n8n on AWS EKS, draw Route 53 → ALB → one main process. ACM supplies the ALB’s TLS certificate. The main queues work in Redis; two workers consume it. PostgreSQL holds workflow and execution records.

Add dedicated webhook processors only when measured ingress load warrants them. Two workers provide execution capacity and redundancy, not main-process availability. Lose the single main and the editor, API and main-handled webhooks are interrupted, even while workers remain healthy.

Diagram 2 — Enterprise multi-AZ availability: draw multiple coordinated main processes across Availability Zones, behind an ALB with sticky sessions. Spread workers across nodes and zones. Use RDS Multi-AZ PostgreSQL and a Redis replication group with automatic failover; extra pods cannot compensate for single-instance dependencies.

n8n queue mode is included in Community; self-hosted multi-main requires Enterprise. Every main and worker must run the same application version and share N8N_ENCRYPTION_KEY. Treat that key as recoverable production data, not disposable pod configuration.

Current documentation supports database binary storage in queue mode, but disallows filesystem mode. External S3 storage is licensed for Business and Enterprise; an S3 bucket alone does not grant entitlement.

Do not confuse n8n’s built-in external-secrets feature with Kubernetes External Secrets Operator. Using the operator to populate pod configuration from AWS Secrets Manager does not imply purchasing n8n’s feature.

Label the second diagram multi-AZ availability, not regional disaster recovery. Assign owners for database recovery, Redis failover and encryption-key restoration. Understanding Cloud Risks explains why ownership and dependency risk belong alongside the architecture.

For a new n8n production deployment, pin the chart and application independently. This baseline uses the n8n official Helm chart 1.17.0, released on 21 October 2026, with n8n 2.44.5. Use that release’s values schema: the repository’s moving main branch has different values.

CHART_VERSION=1.17.0
helm show chart oci://ghcr.io/n8n-io/n8n-helm-chart/n8n --version "$CHART_VERSION"

Save this as values.yaml. Replace all three example hostnames with environment-specific DNS names; the editor and webhook URLs deliberately share one hostname.

image:
  tag: "2.44.5"
replicaCount: 1
queueMode:
  enabled: true
  workerReplicaCount: 2
  workerConcurrency: 5
multiMain:
  enabled: false
secretRefs:
  existingSecret: n8n-core
persistence:
  enabled: false
database:
  type: postgresdb
  useExternal: true
  host: postgres.internal.example
  database: n8n
  user: n8n
  passwordSecret:
    name: n8n-db
    key: password
  ssl:
    enabled: true
    rejectUnauthorized: true
    existingSecret:
      name: rds-ca
      caKey: ca.crt
redis:
  enabled: true
  useExternal: true
  host: redis.internal.example
  tls: true
  passwordSecret:
    name: n8n-redis
    key: password
webhook:
  url: https://automation.example.com
editor:
  url: https://automation.example.com
config:
  extraEnv:
    - name: N8N_DEFAULT_BINARY_DATA_MODE
      value: database
    - name: N8N_PROXY_HOPS
      value: "1"
taskRunners:
  enabled: true
  authToken:
    existingSecret: n8n-runner
    existingSecretKey: token

These are application values, not complete AWS provisioning. You still need PostgreSQL, Redis, networking, ingress and certificates. Pre-create the namespace and referenced Secrets:

• n8n-core: N8N_ENCRYPTION_KEY, N8N_HOST, N8N_PORT and N8N_PROTOCOL. Retain the existing encryption key during migrations or stored credentials become unreadable.
• n8n-db and n8n-redis: their respective password keys.
• rds-ca: the trusted RDS CA bundle under ca.crt; n8n-runner: a strong shared token.

The chart generates EXECUTIONS_MODE and Redis connection variables; do not duplicate them. Pin runner images to the same application release, 2.44.5. Confirm every rendered image, Secret reference and TLS setting before installing. Set N8N_PROXY_HOPS to your actual trusted proxy count, not automatically one.

helm template n8n oci://ghcr.io/n8n-io/n8n-helm-chart/n8n --version "$CHART_VERSION" -n n8n -f values.yaml > rendered.yaml

helm upgrade --install n8n oci://ghcr.io/n8n-io/n8n-helm-chart/n8n --version "$CHART_VERSION" -n n8n --create-namespace -f values.yaml --wait --timeout 10m

Two workers at concurrency five provide ten execution slots, not a CPU or memory budget. Use Understanding Kubernetes Pod Basics to size requests and limits against representative workflows. Reserve migration-specific image pins for section six: do not point this new-install application tag at an existing database.

Before disabling the PVC, inventory database state, encryption keys, binary data, community packages and local files. Each needs a durable home or reproducible replacement. Bake approved community nodes into a versioned image; never depend on mutable installations inside a pod.

For non-queue, single-instance deployments, persistent filesystem storage can be appropriate. An EBS ReadWriteOnce volume is not a shared multi-AZ filesystem. The n8n official Helm chart release README advises Recreate for RWO persistence to avoid multi-attach problems. Accept the replacement downtime explicitly.

Hypothetical failure: replacement pods pass readiness checks but cannot read invoice files left on the previous pod. Green Kubernetes status does not prove workflow recovery.

For licensed S3 storage, the values overlay starts with:

license:
  enabled: true
s3:
  enabled: true

Reference an existing licence Secret, configure the London bucket region as eu-west-2, and enable credential-provider autodetection. Use workload identity rather than static AWS keys. Preserve the existing storage mode during an n8n EKS migration; change storage separately.

Keep retention controls separate. Current n8n external-storage guidance delegates binary cleanup to bucket lifecycle policies. It warns against lifecycle deletion of externally stored execution records still referenced by n8n.

• Place pods in private subnets. Restrict database and cache security groups to required workload sources and ports.
• Verify RDS TLS certificates against the RDS CA bundle. Integrate Secrets Manager through an external-secrets controller or CSI provider.
• Grant least-privilege workload identity access to the required bucket prefixes and secrets.
• Configure ALB with ACM certificates, IP targets and readiness-based health checks.

Enterprise multi-main needs ALB target-group stickiness, not the chart’s nginx-specific toggle; the release README distinguishes them. For the ownership trade-off, see ECS Gateway vs ALB: which ingress should you own?

22 October 2026: eu-west-2 planning comparison. For n8n on AWS EKS, separate infrastructure, licensing and ownership. Use 730 hours monthly. The verified EKS control-plane tariff is $0.10/hour in standard support ($73/month), or $0.60/hour in extended support ($438/month).

Every other infrastructure figure below is an explicit Cloudline budgeting assumption, not an AWS quotation. All amounts are USD/month; add each row to reproduce its total.

Shared EKS assumes an existing cluster; it does not allocate another control plane. Dedicated EKS and Fargate use the same database and Redis allowances. Fargate bills requested CPU/memory; NAT and load balancing have separate usage dimensions. These are modest-workload budgets, not throughput benchmarks or equivalent availability promises. Compose is recovery-oriented, without HA.

Plans, separately: n8n’s annually billed pricing lists Cloud Starter at €20/month for 2,500 executions; Cloud Pro at €50 for 10,000; self-hosted Business at €667 for 40,000; Enterprise by quotation. Cloud subscriptions are alternatives, not self-hosted infrastructure add-ons.

Ownership scenarios: assume £75/hour. Four, eight or twelve hours monthly adds £300, £600 or £900 respectively—not measured averages. Exclude VAT, AWS Support, substantial transfer and third-party API bills. Allocate shared costs explicitly; Lack of Visibility into Costs explains why this matters.

The CNCF case study dated 16 October 2026 documents preserving PostgreSQL, Redis queues, object storage, IAM and secrets across the community-to-official-chart transition. For an n8n EKS migration, add a strict change boundary and acceptance gate.

1. Capture the baseline.

   helm get values OLD_RELEASE -n n8n -a
   helm get manifest OLD_RELEASE -n n8n

   Record image tags/digests, PVC ownership, custom images, retention settings, public URLs and dependency endpoints. Protect these exports: Helm values may contain secrets.
2. Change the chart, not the application. Record the actual running n8n version. Use it as the n8n official Helm chart image override, with matching runners. Exclude PostgreSQL upgrades, queue/storage redesign and n8n upgrades. If that application cannot run on the chosen chart, stage compatibility work separately. Put these boundaries in the cloud migration plan.
3. Restore into isolation. Restore PostgreSQL, the original encryption key and required object data. Use separate Redis or an isolated queue namespace. Block production schedules, callbacks and outbound side effects. Database reuse or a full restore preserves history; workflow JSON exports alone are not a complete state backup.
4. Rehearse the cutover. Pause producers, drain active work and account for delayed/waiting executions. Stop old trigger-owning processes before starting replacements. Prevent autoscalers and GitOps from restarting them. Retain old release artefacts and externally owned state. Do not uninstall old resources until PVC, Secret and service ownership is understood.
5. Enforce pass/fail criteria. Account for every retained workflow and credential. Decrypt a sandbox credential. Open ten sampled retained executions with their attachments. Pass webhook, timer and waiting/resume tests. Require zero duplicate side effects during controlled replay and completion within the agreed maintenance window.
6. Rehearse rollback. Keep only one trigger-owning deployment active throughout reversal. Helm rollback restores Kubernetes release configuration; it cannot undo database schema changes. That is another reason to keep the n8n version unchanged.

Running n8n on AWS EKS needs three closing decisions: Choose an owner. Preserve recoverable state. Prove recovery. Healthy pods are not an acceptance test.

• Platform engineering: owns EKS, node and add-on upgrades, workload identity, ingress and infrastructure recovery.
• Automation owner: owns workflow correctness, approved nodes, retention and downstream idempotency. Replayed executions must not create duplicate payments or tickets.
• Named service owner: owns licence renewals, escalation and the agreed recovery objective. Record a deputy and an out-of-hours escalation route.

Alert on oldest queued work, execution failures, webhook errors, worker restarts, PostgreSQL connections and storage growth—not CPU alone. Low CPU can coexist with a blocked queue.

The n8n official Helm chart supports worker HPA and KEDA queue-based scaling. Choose one worker scaling controller, not competing controllers. Cap replicas against tested database connection limits and downstream capacity; more workers can simply move the outage downstream.

Propose an initial 15-minute RPO and 60-minute RTO for negotiation, not as promises. The service owner must accept the potential data loss and interruption, alongside the cost of reducing them.

1. Restore quarterly: time an isolated restore of PostgreSQL, the encryption key, object data and deployment artefacts. Block production webhooks and outbound side effects.
2. Record evidence: capture the recovered data timestamp, recovery point and elapsed recovery time. Verify credential decryption, sampled execution history and a sandbox end-to-end execution.
3. Test availability separately: rehearse node drain and dependency failover. Neither proves that backups restore successfully.

Bring your current Helm values, workload profile, licence and recovery targets to a production-readiness or n8n EKS migration assessment. Talk to a cloud engineer about what needs proving before production depends on it.

EKS is a strong option when it extends a platform your team already operates well. It is a weaker default when n8n would become the reason to build that platform. Choose the topology and licence together, keep chart migration separate from application upgrades, and demand a restore result before calling the service ready. Cloudline Consulting can help assess production readiness or rehearse a migration using your current deployment, workload profile and recovery targets. Start with those inputs, not a cluster order.