AWS (EC2 / ECS / Lightsail)
Enterprise-grade scale with the full AWS ecosystem.
Run n8n on AWS via EC2 + Docker Compose for simplicity, ECS Fargate for managed containers, or Lightsail for a simplified VPS experience — pair with RDS Postgres for production.
Pros
- VPC, IAM, KMS, PrivateLink
- RDS Postgres + ElastiCache Redis
- Fargate for queue-mode workers
Cons
- Cost surprises without discipline
- Steeper learning curve
Prerequisites
- An AWS account with billing configured
- IAM familiarity (security groups, roles)
- A domain managed in Route 53 or elsewhere
- Comfort with VPC networking for ECS/Fargate
Step-by-step guide
Step 1
Choose a compute option
EC2 t3.small+ for Docker Compose, or ECS Fargate for a serverless container.
Step 2
Provision RDS Postgres
Create a db.t3.micro+ Postgres instance in the same VPC/subnet as your compute.
Step 3
Deploy n8n container
On EC2, use the standard docker-compose.yml pointing DB_POSTGRESDB_HOST at the RDS endpoint. On ECS, define a task definition with the n8n image and RDS env vars.
Step 4
Put an ALB or Caddy in front
Use an Application Load Balancer with an ACM certificate (ECS) or Caddy on the instance (EC2) for HTTPS.
Scaling & queue mode
On ECS/Fargate, run the main n8n service plus a separate worker service in queue mode (EXECUTIONS_MODE=queue) backed by ElastiCache Redis; scale worker task count with Application Auto Scaling based on CPU or Redis queue depth.
Backup & upgrade
Enable RDS automated backups and snapshots; store n8n_data on EFS for ECS or an EBS volume for EC2 so it can be snapshotted too. Upgrade by rolling a new task definition revision or re-pulling the image on EC2.
Security checklist
- Always run behind HTTPS (Caddy/Traefik/Nginx + Let's Encrypt) — never expose port 5678 directly.
- Set a strong, permanent N8N_ENCRYPTION_KEY and back it up (losing it breaks stored credentials).
- Use Postgres, not the default SQLite, for anything beyond local testing.
- Enable N8N_BASIC_AUTH or an SSO/proxy layer if the instance is reachable from the internet.
- Restrict inbound firewall rules to 80/443 (and SSH from your IP only).
- Keep the n8n image pinned and update on a schedule instead of always using :latest in production.
- Lock down security groups to only 80/443 inbound, and SSH via a bastion or Session Manager
- Use IAM roles instead of long-lived AWS keys inside n8n credentials where possible
Cost breakdown
- EC2 t3.small~$15/mo
- RDS db.t3.micro Postgres~$15/mo
- ECS Fargate (0.5vCPU/1GB)~$20–40/mo
Troubleshooting & FAQ
+Can I use SQLite instead of Postgres?
n8n defaults to SQLite, which works for testing but isn't recommended for production: no concurrent writers, harder backups, and risk of corruption under load. Use Postgres for anything real.
+My webhooks return 404 / don't trigger — why?
WEBHOOK_URL must match the public HTTPS URL exactly (including trailing slash), and the workflow must be activated (not just saved) for production webhook URLs to work.
+How do I move from AWS to another host later?
Export workflows/credentials with the n8n CLI (`n8n export:workflow --all` / `export:credentials --all`) or the REST API, restore the Postgres dump on the new host, then import.
+Do I lose data if the container restarts?
No, as long as n8n_data and the Postgres volume are mounted as named Docker volumes (not ephemeral container storage), your data persists across restarts and image updates.