n8n AWS Production Setup Guide

by | Jun 21, 2026 | Blog | 0 comments

n8n AWS Costs: What to Expect in 2026

Published 21 June 2026. Cost figures below are 2026 projections based on AWS on-demand list prices observed in mid-2026; verify against the official AWS pricing calculators linked in the Sources & References section before budgeting, since AWS adjusts pricing periodically and rates vary by region.

Running n8n aws deployments in 2026 costs most SMEs between $15 and $90 per month, depending on your chosen infrastructure approach. A lean Amazon Lightsail setup runs around $12/month, while a production EC2 instance with a managed Postgres database typically lands at $50–$90/month — a flat, predictable bill regardless of how many workflows you execute.

The cost gap between n8n on AWS and task-based tools widens fast. n8n self-hosting charges you for compute, not for execution volume. Whether you run 2,000 or 200,000 workflow runs a month, your AWS bill stays roughly the same. According to the AWS Builder Center walkthrough “Deploying n8n on AWS in under 5 minutes”, a Lightsail + Easypanel.io deployment gets you a production-ready instance for about $12/month — a price point that exposes the “Zapier tax” SMEs quietly pay for years.

Cost breakdown by AWS component

AWS billing for n8n splits across four predictable line items. A mid-tier production setup suitable for a startup running real customer-facing automations totals roughly $50–$60/month on-demand, dropping to ~$40/month with one-year reserved instances. Each line item below is a 2026 projection — check the linked official pricing pages for the exact, current rate in your region:

  • EC2 compute: A t3.medium instance (2 vCPU, 4 GB RAM) runs ~$30/month on-demand, or ~$18/month with a 1-year Standard Reserved Instance — roughly a 40% reduction. Confirm current rates on the AWS EC2 On-Demand Pricing page and the EC2 Reserved Instances Pricing page.
  • RDS PostgreSQL: A single managed instance for workflow data adds ~$13–$15/month on-demand. We standardise on the db.t4g.micro (Graviton/ARM) class because it is typically priced below the older Intel-based db.t3.micro for equivalent vCPU/RAM; see the Amazon RDS for PostgreSQL Pricing page. (Earlier drafts of this guide listed db.t3.micro in some tables and db.t4g.micro in others — the correct, current recommendation is db.t4g.micro everywhere.)
  • EBS storage: A 30 GB gp3 volume adds ~$2.40/month at $0.08 per GB-month. Verify on the Amazon EBS Pricing page.
  • Data transfer: Outbound egress is billed per GB after a free monthly allowance; most SME workflows stay under $5–$10/month. See the data transfer section of the EC2 On-Demand Pricing page.

For comparison, n8n Cloud’s entry tiers bill per execution and per workflow; check the current published rates on the official n8n site. Self-hosting on AWS generally becomes cost-effective above ~10,000 monthly executions, where managed-cloud pricing scales while a fixed EC2 + RDS bill does not. The official n8n AWS hosting guide documents the Postgres-backed, Kubernetes-managed reference architecture if you want to compare against the vendor’s own recommended setup.

AWS-hosted n8n vs Zapier task pricing

AWS-hosted n8n vs Zapier task pricing differs fundamentally: Zapier bills per task, while self-hosted n8n bills per workflow execution regardless of step count. A 50-step workflow consumes 50 Zapier tasks per run but counts as a single n8n execution. A multi-step automation can therefore burn through a task allowance in days, while the same workflow on AWS adds nothing to a flat compute bill.

The illustrative comparison below uses publicly advertised task-tool tiers against a flat AWS server cost. Treat the AWS column as a fixed-infrastructure projection and the task column as representative published pricing rather than a quote:

Volume / MonthTask-based tool (e.g. Zapier)n8n on AWS (flat)
2,000 runs~$49~$50
50,000 runs~$289+~$50
200,000 runs$799+~$90

Break-even arrives early. Past roughly 30,000 monthly executions, n8n on AWS costs a fraction of any task-metered competitor — and the savings compound every month a workflow keeps running. The trade-off, covered in detail below, is that you now own patching, backups, security, and uptime.

Which AWS architecture is best for self-hosting n8n?

n8n aws plays a pivotal role in this context.

The most cost-effective architecture for self-hosting n8n is a single EC2 t3.medium instance paired with Amazon RDS PostgreSQL, for small and medium businesses running under 10,000 workflow executions per day. With 4 GB RAM and 2 vCPUs, this setup handles a handful of concurrent workflows reliably. ECS Fargate becomes justified only at much higher volumes, when horizontal scaling across multiple containers reduces latency during peak loads. Lightsail suits early-stage testing where predictable flat pricing beats granular control.

Practitioners generally find that for the large majority of SMEs, a single EC2 instance with RDS is the sweet spot — Fargate adds operational complexity that most teams do not need until they cross five-figure daily execution counts. Key principles:

  • Use RDS Postgres (not SQLite) to prevent data loss during instance restarts.
  • Allocate at least 4 GB RAM; n8n typically consumes 1.5–2 GB under moderate load.
  • Enable automated RDS backups with at least 7-day retention.
  • Reserve EC2 instances for stable workloads to capture the largest discounts.

EC2 single instance vs ECS Fargate vs Lightsail

A single EC2 instance is the default hosting recommendation for predictable workloads. A t3.medium — ~$30/month on-demand or ~$18/month with a one-year reserved plan — runs the main n8n process plus one worker comfortably for teams processing tens of thousands of executions monthly. EC2 gives you full root access for Docker tuning, swap configuration, and custom node installations.

ECS Fargate decouples compute from server management and lets you run separate main, worker, and webhook tasks that scale independently. Fargate typically carries a 25–40% cost premium over equivalent EC2 capacity, so reserve it for production loads with high daily execution counts or unpredictable spikes.

Lightsail bundles compute, storage, and bandwidth into one fixed monthly bill (starting around $10–$12 for a 2 GB RAM instance). It trades flexibility for simplicity and works well for proof-of-concept builds, but its limited instance ceiling and lack of native RDS integration make it a poor long-term production home. The AWS Builder Center guide above documents the Lightsail + Easypanel.io path in full.

Database choice: RDS Postgres vs local Postgres

RDS Postgres is the production-grade choice for self-hosted n8n because it delivers automated daily backups, point-in-time recovery within a configurable retention window, and Multi-AZ failover — capabilities a local Postgres container cannot match. A db.t4g.micro instance costs roughly $13–$15/month and eliminates the single largest failure point in self-hosted deployments: losing execution history and workflow state when a container crashes or a host disk fails. Confirm the rate on the Amazon RDS for PostgreSQL Pricing page.

By contrast, local Postgres running in a Docker volume offers no managed recovery; a corrupted volume can mean total data loss. Multi-AZ RDS replicates synchronously to a standby in a separate availability zone and fails over automatically. For any n8n instance running revenue-critical automations, the ~$15/month premium is small against the cost of reconstructing lost workflows and execution logs.

Local Postgres (running in the same Docker Compose stack) cuts cost to zero beyond your EC2 bill, which suits staging or low-stakes internal automations — but it becomes a liability in production, where one unmounted volume or failed disk wipes every stored credential and workflow.

When to enable queue mode with Redis

Queue mode with Redis becomes necessary once a single n8n process can no longer execute workflows fast enough — typically when long-running workflows block the main thread or executions begin to queue. Redis acts as the message broker between the main instance and dedicated worker processes.

  • Stay single-process below ~10,000 executions/day with short-running flows.
  • Enable queue mode when executions queue up, webhooks time out, or you need horizontal worker scaling.
  • Use ElastiCache Redis (cache.t4g.micro, ~$12/month) over a self-managed Redis container for production reliability.

How do you deploy n8n on AWS securely?

Integrating n8n aws into your strategy ensures a competitive edge.

Deploying n8n on AWS securely requires a private VPC, a hardened EC2 instance running n8n in Docker, an external RDS PostgreSQL database, and an Nginx reverse proxy with SSL. A correct setup isolates network access, enforces TLS, and locks down credentials with least-privilege IAM roles.

Misconfigured n8n instances are a real risk: internet-wide scans have repeatedly surfaced exposed n8n editor UIs with no authentication, leaking webhook endpoints and credential metadata. Because n8n is fair-code and the source is public on the official n8n GitHub repository, attackers know exactly which ports and paths to probe — making a correct deployment non-optional. Always pin a specific release tag from the repository rather than tracking latest.

Step-by-step secure deployment (n8n ec2 deployment walkthrough)

The following is a typical, reproducible n8n ec2 deployment. Commands assume Ubuntu 22.04 LTS; adjust package commands for Amazon Linux 2023.

  1. Provision a VPC with public and private subnets. Place EC2 in the public subnet (for web traffic) and RDS in private subnets with no internet route.
  2. Launch EC2 — a t3.medium running Amazon Linux 2023 or Ubuntu 22.04 LTS handles most SME workloads. Disable password SSH; use key-pair authentication only.
  3. Install Docker and Docker Compose on the instance:
    sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu $(. /etc/os-release; echo $VERSION_CODENAME) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo usermod -aG docker $USER
  4. Create the n8n environment file (.env) — never commit this to source control and keep N8N_ENCRYPTION_KEY backed up in Secrets Manager:
    # .env
DOMAIN=n8n.example.com
N8N_HOST=n8n.example.com
N8N_PROTOCOL=https
N8N_PORT=5678
WEBHOOK_URL=https://n8n.example.com/

# Database (point at the private RDS endpoint)
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=n8n-db.xxxxx.eu-west-1.rds.amazonaws.com
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n_app
DB_POSTGRESDB_PASSWORD=__from_secrets_manager__

# Auth & encryption
N8N_BASIC_AUTH_ACTIVE=true
N8N_BASIC_AUTH_USER=admin
N8N_BASIC_AUTH_PASSWORD=__strong_unique_value__
N8N_ENCRYPTION_KEY=__generate_once_and_store__
GENERIC_TIMEZONE=Europe/London
  5. Define the Docker Compose stack, pinning a specific version tag (never :latest in production):
    # docker-compose.yml
services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:1.XX.X   # pin a real release tag
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"   # bind to localhost; Nginx fronts it
    env_file: .env
    volumes:
      - n8n_data:/home/node/.n8n
volumes:
  n8n_data:

    Then start it: docker compose up -d

  6. Configure Nginx as a reverse proxy in front of n8n’s port 5678, handling all inbound HTTPS:
    # /etc/nginx/sites-available/n8n
server {
    listen 80;
    server_name n8n.example.com;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl;
    server_name n8n.example.com;

    ssl_certificate     /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";   # required for n8n WebSockets
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
  7. Issue SSL via Let’s Encrypt using Certbot. Free 90-day certificates auto-renew, eliminating the certificate cost line entirely:
    sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d n8n.example.com
sudo systemctl reload nginx
  8. Tighten security groups: allow only 443 (and 80 for cert renewal) from the internet, 22 from your IP only, and 5432 strictly between the EC2 security group and the RDS security group — never from the public internet.

Caddy is a common alternative to Nginx for steps 5–6 because it provisions and renews TLS automatically with a two-line config; community guides frequently pair n8n with Caddy on EC2. Either reverse proxy is fine — the security requirement is that n8n’s port 5678 is never reachable directly from the internet.

Hardening authentication

n8n authentication should be enforced at multiple layers. Set N8N_BASIC_AUTH_ACTIVE=true with a strong username and password to gate the editor UI. For inbound webhooks, attach header authentication or HMAC signature validation inside your workflows — public webhook URLs are otherwise callable by anyone who guesses the path.

Webhook hardening matters because every n8n trigger URL is a live API endpoint. Adding a shared-secret header check or signature verification node blocks unauthenticated payloads before they touch downstream logic. (Note: in newer n8n releases the user-management/owner account model supersedes basic auth for the UI; review the version-specific guidance in the official n8n hosting documentation for your pinned release.)

IAM least-privilege roles

IAM least-privilege means the EC2 instance role grants only the exact permissions n8n needs — S3 reads for a specific bucket, SES send for one domain, Secrets Manager access for stored credentials. Avoid attaching broad managed policies like AdministratorAccess.

Storing API keys in AWS Secrets Manager rather than plain environment variables limits exposure: a compromised container cannot dump every credential, and rotation happens without redeploying. Treating least-privilege roles as the default — not an afterthought — is a baseline practitioners apply across production n8n implementations.

AWS hosting options compared

n8n aws is a core pillar of sustained growth.

AWS offers three viable hosting paths for n8n in 2026: EC2 (full-control virtual machines), Fargate (serverless containers), and Lightsail (fixed-price simplified instances). Each targets a different combination of cost predictability, scaling ceiling, and operational effort — and choosing wrong can inflate your bill several times over at scale. AWS also publishes two official AWS Marketplace listings for n8n with CloudFormation templates for both Community and Enterprise editions, plus a second Marketplace listing backed by 24×7 AWS infrastructure support — a useful option if you want a templated launch rather than a hand-built stack.

OptionMonthly Cost (baseline, 2026 projection)ScalabilitySetup EffortBest For
Lightsail$10–$40 (fixed)Low (manual resize)MinimalSolo founders, MVPs
EC2$15–$120+ (variable)High (auto-scaling groups)Moderate–HighProduction SMEs
Fargate (ECS)$30–$200+ (per-task)Very High (queue mode)HighHigh-throughput teams

Lightsail wins on predictability — a ~$20/month bundle (2 vCPU, 2 GB RAM) handles roughly 10,000 executions monthly without surprise charges. EC2 trades that simplicity for control: spot instances can cut compute costs substantially versus on-demand pricing (see the EC2 pricing page for current spot and on-demand rates), and reserved instances lock in roughly 40% savings over a 12-month term per the EC2 Reserved Instances Pricing page. Fargate eliminates server patching entirely but charges per vCPU-second, which punishes idle workflows and rewards spiky, batch-heavy automation.

Recommended config by execution volume

Execution volume — not user count — should drive your AWS architecture decision for n8n. A workflow firing 50 nodes per run consumes far more compute than a simple two-step webhook, so size against real throughput rather than vanity metrics.

  • Under 10,000 executions/month: Lightsail $20 bundle (2 vCPU, 2 GB RAM) with a small RDS PostgreSQL instance. Total cost: ~$20–$35/month. No queue mode needed.
  • Under 100,000 executions/month: EC2 t3.medium (2 vCPU, 4 GB RAM) running n8n in queue mode with Redis and RDS PostgreSQL (db.t4g.micro). Total cost: ~$70–$110/month. Add one worker container for resilience.
  • Over 1,000,000 executions/month: Fargate ECS with queue mode, 3–5 worker tasks behind an Application Load Balancer, RDS PostgreSQL (db.t4g.medium or larger), and ElastiCache Redis. Total cost: ~$250–$450/month, auto-scaling on queue depth.

Benchmark every deployment against this volume ladder before provisioning a single resource — over-provisioning at the 10k tier is the self-hosting equivalent of the Zapier tax you left to escape.

How do you scale n8n on AWS for production?

Applying n8n aws delivers measurable results over time.

Scaling n8n on AWS for production requires queue mode with Redis-backed BullMQ, dedicated worker containers behind an autoscaling group, and CloudWatch-driven alerts. A single n8n process caps out at a few hundred concurrent executions; queue mode with multiple workers pushes throughput substantially higher on modest ECS Fargate tasks.

Queue mode and worker autoscaling

Queue mode decouples the n8n main process (which handles the UI and webhooks) from worker processes that execute workflows. Redis acts as the message broker via BullMQ. Set EXECUTIONS_MODE=queue, point n8n at an ElastiCache Redis cluster, and run workers as a separate ECS service scaled by an Application Auto Scaling target tracking the Redis queue depth metric.

Worker autoscaling on AWS follows a clean pattern. Configure each worker with --concurrency=10, then scale the worker service when queue depth exceeds a threshold:

  1. Publish a custom CloudWatch metric for Redis queue length using a Lambda polling function (every 60 seconds).
  2. Create a target-tracking scaling policy targeting 50 queued jobs per worker.
  3. Set min capacity to 2 workers and max to 20 to absorb traffic spikes without idle cost.
  4. Enable scale-in cooldowns of 300 seconds to avoid thrashing during bursty loads.

Backup, disaster recovery, and failover

Backup discipline separates a hobby deployment from a production one. The n8n state lives in PostgreSQL, so RDS automated backups with at least 7-day retention plus point-in-time recovery cover the database. Store the encryption key (N8N_ENCRYPTION_KEY) in AWS Secrets Manager — losing it means every saved credential becomes unrecoverable.

  • RDS Multi-AZ: automatic failover, adding roughly $25/month for a db.t4g.medium standby; confirm on the RDS for PostgreSQL Pricing page.
  • Cross-region snapshots: copy RDS and ElastiCache snapshots to a second region for disaster recovery.
  • ECS service redundancy: run the main process across two Availability Zones behind an Application Load Balancer.

Monitoring with CloudWatch and Grafana

Monitoring closes the loop on production reliability. CloudWatch Container Insights tracks CPU, memory, and task health for every ECS service, while n8n’s Prometheus metrics endpoint (N8N_METRICS=true) feeds execution counts, failure rates, and queue latency into Grafana.

Grafana dashboards expose the metrics that actually matter: workflow failure rate, average execution duration, and Redis queue backlog. Set CloudWatch Alarms on failure rate above 2% and queue depth above 500 jobs, routed through SNS to Slack. Teams that instrument this way catch silent workflow failures within minutes instead of discovering them days later through missing data.

Frequently Asked Questions

n8n aws is one of the most relevant trends shaping 2026.

Is AWS cheaper than n8n Cloud?

AWS generally becomes cheaper than n8n Cloud once you exceed roughly 5,000–10,000 workflow executions per month, because self-hosting bills for compute rather than per execution. A self-hosted t3.small or t3.medium EC2 setup with RDS runs a flat monthly fee with unlimited executions. Always compare against the current published rates on the official n8n site, as cloud tiers change.

The break-even shifts further in AWS’s favour at scale — a startup running 100,000 executions monthly pays a flat infrastructure bill on EC2 + RDS regardless of volume. The trade-off is operational overhead: you own patching, backups, and uptime. For SMEs already comfortable with AWS, self-hosting eliminates the per-execution pricing model entirely.

What EC2 instance size do I need for n8n?

A t3.small (2 vCPU, 2 GB RAM) handles most SME workloads under 10,000 executions per month. For production with queue mode and heavy data transformations, a t3.medium (2 vCPU, 4 GB RAM) provides comfortable headroom.

n8n is memory-hungry when processing large payloads or running multiple concurrent workflows. Single-execution workloads (webhooks, simple API calls) survive on a t3.micro, but Node.js will swap and crash under load. Budget 4 GB RAM minimum for any deployment touching real business data.

How do I secure n8n webhooks on AWS?

Secure n8n webhooks on AWS by placing the instance behind an Application Load Balancer with an ACM SSL certificate, restricting inbound traffic to HTTPS (port 443) only, and enabling webhook authentication tokens inside n8n.

Webhook endpoints are the most exposed attack surface in any n8n deployment. Lock them down with these layers:

  • AWS WAF — block common injection and bot traffic at the load balancer
  • Security groups — allow only 443 inbound, never expose port 5678 publicly
  • Header-based auth — validate a secret token on every incoming webhook
  • Rate limiting — throttle requests to prevent abuse and runaway costs

Can I run n8n queue mode on a single EC2 instance?

Yes, n8n queue mode runs on a single EC2 instance using Docker Compose with a Redis container and separate worker processes. A single t3.medium can host the main process, one or two workers, and Redis without dedicated nodes.

Queue mode on one box still delivers the core benefit — execution isolation so a stuck workflow doesn’t freeze the entire instance. Scale to dedicated worker nodes only when CPU sits above 70% consistently.

Bottom line: A ~$25/month t3.medium with queue mode is highly competitive against managed-cloud tiers at 100,000 executions — provided you treat security groups, reverse-proxy TLS, and webhook auth as non-negotiable, not optional.

Sources & References

n8n aws plays a pivotal role in this context.

This guide reflects general AWS and n8n self-hosting practice as of June 2026. Cost figures are 2026 projections based on published AWS list prices and should be verified against the official, dated pricing pages below before budgeting.

Author note: This article is maintained by J. SERVO’s topical team focused on AWS infrastructure and workflow automation. It is based on documented AWS and n8n practices rather than a single named deployment; verify all pricing and version-specific behaviour against the official sources above before going to production.



Last updated: 2026-06-21

Submit a Comment

Your email address will not be published. Required fields are marked *