Run n8n like production infrastructure, not a single container.
Out of the box, n8n is one container doing the UI, the API, the triggers, and the execution, so one crash means your automations stop. This is my reference architecture for running it highly-available and self-healing on AWS.
Reference architecture (RTO/RPO below are design targets, not measured production numbers).
* design targets for this reference architecture
n8n's default deployment is a single point of failure: one process runs the UI, the API, the triggers, and the workflow execution. A crash or a lost host means downtime, and in-flight executions can be interrupted or lost. A single node can't absorb spikes, upgrades are risky, and there's no real disaster-recovery story.
n8n in queue mode on ECS Fargate: the main (web/API) service and the worker service separated and scaled independently, run in at least two availability zones behind an Application Load Balancer. Health checks drain and replace failed tasks automatically; a Multi-AZ Postgres and a shared encrypted filesystem keep state durable; autoscaling tracks CPU and memory; a deployment circuit-breaker auto-rolls-back a bad release; tiered backups plus cross-region export cover disaster recovery; and a workers-first rolling pipeline ships new n8n versions with zero downtime. All of it is Terraform, deployed through OIDC CI/CD with no static keys.
- Multi-AZ
- queue mode
- auto-heal
- auto-rollback
- DR
The design targets: no single point of failure, failed tasks replaced automatically, executions kept durable through queue mode + Postgres, and a documented recovery path for every failure mode, from a single-AZ blip (RTO 5–10 min, RPO 0) up to a full region loss. Version upgrades ship with zero downtime, and every deploy is one approval-gated, fully-reproducible pipeline run.
* design targets for this reference architecture
[ reference architecture · RTO/RPO are design targets, not measured production numbers ]
What the architecture gives you.
Six properties this reference architecture is designed for, every one of them defined in Terraform.
Queue mode
The main (web/API) service and the worker service run as independent services, separated so each scales on its own.
Multi-AZ + self-healing
Tasks run across at least two availability zones; health checks replace any unhealthy task automatically.
Tiered backups + cross-region DR
Daily, weekly, and monthly backups, plus snapshot export to a second region for disaster recovery.
Zero-downtime upgrades
A workers-first rolling deploy ships new n8n versions without downtime, with automatic rollback on failure.
OIDC CI/CD
Every deploy runs through an approval-gated pipeline that authenticates with OIDC. No long-lived cloud keys stored anywhere.
Defense-in-depth
Scoped security groups, private subnets, vaulted secrets, and encryption at rest and in transit. Layered, not bolted on.
Designed to heal itself before anyone gets paged.
The parts that keep n8n up when a task, a zone, or a release goes wrong.
Self-healing
- ALB and container health checks drain and replace unhealthy tasks automatically.
- A deployment circuit-breaker rolls back failed releases automatically.
Safe upgrades
- Detects the latest n8n version, then updates workers first and main second.
- Waits for the service to reach stable before the rollout completes.
Durable by design
- Multi-AZ Postgres and a shared encrypted EFS keep state off the tasks.
- Any task can be replaced without losing workflows or executions.
Reproducible
- 5 Terraform modules, ~65 AWS resources, three sized environments.
- State is locked and encrypted: stand it up in any account or region.
* design targets for this reference architecture
Your automations shouldn't have a single point of failure.
Tell me what you're automating and where it runs today. I'll map out the highly-available version: main and workers split across zones, health-checked recovery, and the whole thing reproducible in Terraform.