Thursday, July 16, 2026

Best Way to Host n8n on AWS EC2 (With Examples)

Written by   on   in   with No comments

Best Way to Host n8n on AWS EC2 (With Examples)

n8n (pronounced "n-eight-n"), an open-source workflow automation platform launched in October 2019 by Berlin-based founder Jan Oberhauser, connects 400+ apps and services in a visual node-based editor. By April 2021, its community had grown to roughly 16,000 developers and citizen developers. But here's the pain point most users hit: n8n's cloud tier caps executions, and self-hosting on a local machine kills uptime. Running n8n on AWS EC2 gives you full control, unlimited workflows, and production-grade reliability for pennies a day. This guide walks you through the exact setup with real examples, from a t4g.nano budget build to a load-balanced production cluster.

Quick Answer: Launch an EC2 t4g.nano or t3a.micro instance running Ubuntu 24.04, install n8n via Node.js (or Docker), configure an Elastic IP and Security Group for HTTPS, and use a reverse proxy (Nginx + Let's Encrypt). Cost: $4–$12/month. Best for unlimited workflows, full data control, and zero per-execution fees.

Why EC2 Beats Alternatives for n8n Self-Hosting

Before jumping into commands, you need to understand why EC2 is the right compute layer. n8n runs on Node.js and TypeScript, and each workflow execution consumes CPU and RAM. On a shared cloud plan (n8n Cloud, Zapier, Make), you pay per workflow step or execution. On EC2, you pay a flat hourly (or per-second) rate for the instance, regardless of how many automations you run — as long as you stay within the instance's resource limits.

Spot Pricing vs. On-Demand

AWS introduced EC2 in August 2006 and launched spot instances to let you bid on unused capacity. For n8n, spot instances can cut costs by 60–90%. An on-demand t4g.nano runs about $4.18/month; the same instance on spot pricing costs roughly $1.25/month. The catch: AWS can reclaim a spot instance with a two-minute warning. To handle this, pair spot instances with an Elastic IP and an EBS snapshot recovery script, or use an on-demand instance for the control plane and spot instances for worker nodes.

Instance Family Selection

n8n is burst-friendly but sustained loads need consistent performance. The T4g family (Graviton2, ARM-based) delivers the best price-to-performance ratio for n8n because ARM instances cost 20% less than x86 equivalents. For lightweight personal use, a t4g.nano (2 vCPUs burst, 0.5 GiB RAM) works. For teams running 20+ active workflows, a t4g.small (2 vCPUs, 2 GiB RAM) or t3a.micro is safer. The Nitro hypervisor, introduced by AWS in November 2017, gives all modern instances near-bare-metal network performance with EBS-optimized storage by default.

Data Persistence with EBS

n8n stores workflow definitions, credentials, and execution history in a SQLite database by default (or PostgreSQL in production). EC2 instance stores are ephemeral — terminate the instance and everything disappears. Always attach a gp3 EBS volume (16 GB minimum, $0.08/GB/month) as the root device. Schedule daily EBS snapshots via AWS Backup to protect against corruption or accidental termination.

Step-by-Step: Deploy n8n on a t4g.nano EC2 Instance

This example walks you through launching a production-ready n8n instance on the cheapest viable EC2 type. Total setup time: 25 minutes.

Step 1 — Launch the Instance

  1. Log into AWS Console → EC2 → Launch Instance.
  2. Name: n8n-prod.
  3. Application and OS Images: Ubuntu Server 24.04 LTS (HVM), ARM64 architecture.
  4. Instance type: t4g.nano.
  5. Key pair: Create or select an existing .pem key.
  6. Network settings: Create security group with these inbound rules — SSH (port 22, your IP only), HTTP (port 80, 0.0.0.0/0), HTTPS (port 443, 0.0.0.0/0).
  7. Configure storage: 16 GB gp3 root volume.
  8. Launch.

Step 2 — Assign Elastic IP and Configure DNS

  1. Go to EC2 → Elastic IPs → Allocate Elastic IP address (use Amazon's pool of IPv4 addresses).
  2. Associate it to your n8n instance.
  3. In Route 53 (or your DNS provider), create an A record pointing n8n.yourdomain.com to this Elastic IP.

Step 3 — Install n8n via Docker

ssh -i your-key.pem ubuntu@n8n.yourdomain.com
sudo apt update && sudo apt upgrade -y
sudo apt install docker.io docker-compose-v2 -y
sudo systemctl enable docker
mkdir ~/n8n && cd ~/n8n

Create a docker-compose.yml file:

version: '3.8'
services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      - N8N_PORT=5678
      - WEBHOOK_URL=https://n8n.yourdomain.com
      - DB_TYPE=sqlite
      - DB_SQLITE_DATABASE=/home/node/.n8n/database.sqlite
    volumes:
      - ./n8n_data:/home/node/.n8n
docker compose up -d

Verify: docker ps should show the n8n container running on port 5678.

Step 4 — Set Up Nginx Reverse Proxy and SSL

sudo apt install nginx certbot python3-certbot-nginx -y
sudo nano /etc/nginx/sites-available/n8n

Paste this config:

server {
    listen 80;
    server_name n8n.yourdomain.com;
    location / {
        proxy_pass http://localhost:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_buffering off;
    }
}
sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d n8n.yourdomain.com

Example output: Certbot issues a Let's Encrypt certificate valid for 90 days, auto-renewed via a systemd timer. Your n8n instance is now live at https://n8n.yourdomain.com.

Production-Grade: n8n with PostgreSQL and Multiple Workers

For teams running 50+ workflows or mission-critical automations, the single-container SQLite setup won't cut it. Production n8n deployments need a separate database, a message queue for scaling workers, and a load balancer.

Database: SQLite vs. PostgreSQL

SQLite works for single-user setups with under 200 workflow executions per day. Beyond that, write locks cause retries and dropped executions. PostgreSQL handles concurrency properly. Migrate by spinning up an RDS db.t4g.micro (PostgreSQL 16, 20 GB storage, ~$15/month) and pointing n8n to it via environment variables DB_TYPE=postgresdb, DB_POSTGRESDB_HOST, DB_POSTGRESDB_USER, etc.

Queue Mode for Horizontal Scaling

n8n's queue mode, introduced in v0.200.0, uses Redis as a message broker. One main instance sends execution jobs to one or more worker instances. This lets you scale workers horizontally on cheaper spot instances while the main instance stays on-demand. Example architecture:

  1. Main node (t3a.small, on-demand): Runs the n8n editor and acts as the webhook receiver. Fronted by an Application Load Balancer.
  2. Redis (ElastiCache cache.t4g.micro, ~$13/month): Message queue.
  3. Workers (t4g.nano, spot): Run n8n worker --concurrency=10. Auto-scaled via a launch template and ASG with min=2, max=10.
  4. RDS PostgreSQL (db.t4g.micro): Shared database.
  5. EBS snapshots via AWS Backup: Daily snapshots of the main node's config volume, retained for 30 days.

Real Example: Marketing Agency Running 120 Workflows

A mid-size marketing agency migrated from n8n Cloud (Pro plan, $200/month) to this setup. They run 120 active workflows (CRM sync, email sequences, ad reporting, Slack notifications). Total monthly AWS cost: $47.32 — main node ($8.60) + 3 spot workers ($3.15) + RDS ($14.98) + Redis ($12.60) + ALB ($7.99). Execution limit: unlimited. Data sovereignty: all customer PII stays on their own encrypted EBS volumes.

Comparison: EC2 Options for n8n Hosting

Choosing the right EC2 configuration depends on your workflow volume, budget, and uptime requirements. The table below compares the five most common setups used by the n8n community.

All costs include compute (us-east-1 on-demand pricing, 730 hours/month), 16 GB gp3 EBS, and Elastic IP (free while attached).

Setup NameInstance & ConfigMonthly Cost
Budget Solot4g.nano, SQLite, Docker, Nginx + Let's Encrypt, no backup$4.18
Standard Solot4g.small, SQLite, Docker, Nginx + SSL, daily EBS snapshot$8.36
Team (PostgreSQL)t3a.medium + db.t4g.micro (RDS), Docker Compose, Redis optional$36.12
Production Queuet3a.small (main) + 2 t4g.nano workers (spot) + RDS + ElastiCache Redis + ALB$47.32
High-Availability2 t3a.medium (active/passive) + RDS Multi-AZ + ElastiCache + ALB + Route 53 failover$124.50

Common Mistakes and How to Fix Them

Mistake 1: Running n8n on a t2.micro (Free Tier)

Why It Hurts: The t2.micro has 1 GiB RAM and CPU credits that deplete fast. n8n's Node.js runtime plus webhook handling consumes 500–700 MB at idle. A single complex workflow (e.g., HTTP request + XML parse + 3 API calls) burns 40+ CPU credits. Once credits hit zero, the instance throttles to 10% CPU, causing workflow timeouts and 502 errors from Nginx. Users report crashes within 48 hours on the free tier with even moderate use.

Fix: Use a t4g.nano ($4.18/month) instead. It has 0.5 GiB RAM but Graviton2 efficiency and burst credits that replenish faster. Or step up to t4g.small ($8.36/month) for 2 GiB RAM — the sweet spot for 5–15 active workflows.

Mistake 2: Exposing Port 5678 Directly

Why It Hurts: n8n's default port has no built-in rate limiting or WAF. Publicly exposing port 5678 invites brute-force login attempts, credential stuffing, and DDoS on your webhook endpoints. A scan on Shodan shows thousands of n8n instances with unprotected dashboards. In March 2024, CVE-2024-1313 disclosed a server-side request forgery vulnerability in n8n that required the dashboard to be behind a proper reverse proxy.

Fix: Always put n8n behind Nginx or an ALB. In the security group, allow inbound on port 5678 only from 127.0.0.1 (or the ALB's security group). Use proxy_pass http://localhost:5678 and never expose the raw port. Add proxy_set_header X-Forwarded-Proto $scheme to prevent protocol mismatch errors.

Mistake 3: Skipping Backups

Why It Hurts: SQLite stores everything in a single file. A corrupted database due to unclean shutdown, full disk, or memory pressure wipes all your workflows. Without backups, recovery requires rebuilding 50+ workflow connections from memory — a multi-day task. AWS terminated 0.5% of spot instances during rebalancing in 2023, and EC2 host failures, though rare (under 0.1% annually per AWS SLA), do happen.

Fix: Set up automated daily EBS snapshots via the AWS Backup service ($0.05/GB/month for backup storage). For PostgreSQL, enable automated backups on the RDS instance with a 7-day retention period. For extra safety, run n8n export:workflow --all weekly and push the JSON output to an S3 bucket versioned with lifecycle rules.

Mistake 4: Ignoring Webhook Timeouts

Why It Hurts: ALB default idle timeout is 60 seconds. Nginx proxy timeout defaults to 60 seconds. n8n workflows that call slow APIs (e.g., OpenAI GPT-4 with 30-second response times) or process large files (PDF parsing, image processing) frequently exceed these limits, returning 504 Gateway Timeout to the caller. The webhook call fails, the source app retries, and you get duplicate execution entries.

Fix: In your Nginx config, add proxy_read_timeout 300s and proxy_send_timeout 300s. For ALB, increase the idle timeout to 300 seconds under the target group settings. Better yet, use n8n's "Wait" node to offload long-running tasks to background workers via queue mode — this keeps webhook responses fast (under 5 seconds) while the heavy processing happens asynchronously.

Mistake 5: Using the Default SQLite in Production

Why It Hurts: SQLite uses file-level locking. When two webhooks fire simultaneously (common with Stripe payment events or Slack slash commands), one execution waits for the write lock. Under 50 concurrent executions per minute, this causes ~12% of workflows to fail with "database is locked" errors. SQLite also lacks row-level encryption, making it unsuitable for GDPR or HIPAA-compliant workloads.

Fix: Migrate to PostgreSQL 16 on RDS. Enable encryption at rest (AES-256) and enforce SSL connections. Use RDS Proxy for connection pooling to handle spikes in workflow concurrency. The migration script: stop n8n, export workflows via n8n export:workflow --all, change environment variables, restart n8n on the new database, and re-import workflows.

Pro Tips

  • Deploy n8n using the official n8nio/n8n Docker image rather than a manual Node.js install. Docker isolates dependencies and makes version upgrades a one-line docker compose pull && docker compose up -d command.
  • Enable n8n's built-in N8N_METRICS=true and pipe metrics to CloudWatch for monitoring. Set a CloudWatch alarm that triggers an SNS notification when memory usage exceeds 80% for 5 consecutive minutes.
  • Pin your n8n Docker image version (e.g., n8nio/n8n:1.70.0) instead of using :latest. Breaking changes between minor versions have broken webhook signatures twice in 2024–2025.
  • Use AWS Systems Manager Parameter Store or Secrets Manager for storing n8n credentials (API keys, database passwords) instead of hardcoding them in docker-compose.yml. Reference them via SSM Run Command at container start.
  • Set up a health check endpoint in n8n (/healthz) and attach it to an ALB target group health check on path /healthz with interval 30 seconds and threshold 2. This auto-replaces unhealthy containers within 60 seconds.

FAQ

What is n8n and how does it work on AWS EC2?

n8n is a source-available workflow automation platform written in Node.js and TypeScript that lets you connect 400+ apps via a visual node editor. On AWS EC2, n8n runs as a Docker container or bare-metal Node.js process, hosted on a virtual machine instance that you control entirely. Compared to n8n Cloud, self-hosting on EC2 removes per-execution fees and keeps your data within your own AWS account.

How does hosting n8n on EC2 compare to using n8n Cloud or a VPS?

EC2 gives you granular control over instance sizing, networking, IAM roles, and scaling policies that a standard VPS (DigitalOcean Droplet, Linode) cannot match, such as attaching to an ALB or using VPC endpoints to S3. n8n Cloud costs $20/month (Starter) but caps you at 2,500 executions/month. EC2 costs $4–$12/month for the same or higher execution volume with zero execution caps. The tradeoff: you manage patching, backups, and security yourself.

What is the cheapest way to host n8n on AWS EC2 step by step?

Launch a t4g.nano instance with Ubuntu 24.04, assign an Elastic IP, install Docker and Docker Compose, run the n8n container with SQLite, set up Nginx as a reverse proxy on port 80/443, and secure it with Let's Encrypt via Certbot. Total monthly cost: $4.18 (compute) + $0.10 (EBS) = ~$4.28. For detailed commands, follow the step-by-step example in Section 2 above.

Why does my n8n instance return 502 or 504 errors, and how do I fix it?

A 502 error usually means n8n's Docker container crashed due to out-of-memory (OOM) — check docker logs n8n for "killed" messages. Fix by upgrading to a larger instance type (t4g.small with 2 GiB RAM) or adding a swap file. A 504 error means the webhook response timed out. Increase proxy_read_timeout in Nginx to 300 seconds, or move long-running tasks to queue mode workers to decouple webhook responses from heavy processing.

Will n8n on EC2 remain cost-effective as AI-powered workflows grow?

Yes. n8n's October 2025 release added native AI agent nodes (OpenAI, Anthropic, Hugging Face) that run inline in workflows. EC2's GPU instances (G4dn, G6f with fractional NVIDIA L4 GPUs) can host local LLMs via Ollama or vLLM, completely eliminating per-token API costs. The G6f instance, announced in 2025, lets you provision one-eighth of an L4 GPU — ideal for running a local 7B parameter model alongside n8n for under $50/month.

Conclusion

Hosting n8n on AWS EC2 is the smartest path for anyone who wants unlimited workflow executions, complete data control, and the ability to scale from a single personal automation to a multi-worker production cluster. The t4g.nano at $4.18/month is the cheapest viable entry point, while the production queue setup at $47.32/month handles 120+ workflows for a fraction of what n8n Cloud or Zapier would charge. The key is choosing the right instance family (Graviton2 for cost, Nitro for performance), never exposing raw ports, always backing up your database via EBS snapshots or RDS automated backups, and moving to PostgreSQL and queue mode before you hit concurrency limits. With the examples and configurations above, you can deploy a production-ready n8n instance in under 30 minutes and pay less than a streaming subscription for enterprise-grade automation infrastructure.

  • Use t4g (Graviton2) instances for the best price-to-performance ratio on n8n workloads.
  • Always front n8n with Nginx or an ALB — never expose port 5678 directly.
  • Migrate to PostgreSQL + queue mode before exceeding 200 daily executions across 20+ workflows.
  • Pin Docker image versions and automate EBS snapshots to prevent data loss from breaking changes or instance failure.

Sources

Share:

0 comments:

Post a Comment