What You Need to Self-Host n8n: Specs, Tradeoffs, Gotchas

TL;DR:

• When you self-host n8n Community Edition, it's free — unlimited executions, no license fees. Paid self-hosted plans (Business and Enterprise) are available if you need SSO, Git version control, or dedicated support.
• RAM is the bottleneck. 2 GB is the documented minimum; 4-8 GB is where production starts working.
• PostgreSQL for production. SQLite works for testing, but locks under concurrent webhooks and can silently drop data. If you started on SQLite, prune execution history before migrating.
• Pin N8N_WEBHOOK_URL to your domain. Without it, webhooks break on every container restart.
• Back up N8N_ENCRYPTION_KEY externally. Losing it means permanently losing every credential in every workflow.

To meet n8n hosting requirements on is*hosting, start with a VPS with n8n pre-installed. Medium VPS (3 vCPU, 4 GB, 40 GB NVMe, from $21.24/mo) — minimum production for single-instance n8n with moderate traffic. PostgreSQL runs on the same machine in Docker, but there's no headroom for heavy payloads or AI calls.

What Self-Hosting n8n Costs You

The Community Edition is free under the Sustainable Use License (what n8n calls "fair-code") — unlimited executions, unlimited workflows, unlimited users, all 400+ integrations, and AI nodes included. The license allows internal business use, but prohibits embedding n8n into a product you sell to external users.

That's the version most self-hosters use, and it's what this n8n self-hosting guide covers.

If your team needs SSO, LDAP, Git-based version control, or multi-environment support, n8n offers a self-hosted Business plan (€800/mo with a license key) and an Enterprise tier with custom pricing and SLAs. Those are real requirements for regulated companies — but for indie developers, startups, and technical teams, Community Edition has everything you need.

The tradeoff is the same either way: everything the SaaS version handles — database, SSL, scaling, backups — is now yours. You're signing up to be your own SRE, on-call included. And n8n still can't be fully provisioned programmatically — the initial owner account and API key require manual setup via UI, which feels like 2019 in the worst way.

Worth it for most teams running serious automation. But go in with the right specs and defaults, not vibes.

n8n Server Requirements: Minimum vs Recommended

Understanding n8n server requirements starts with the question: What are your workflows doing?

A lead-routing webhook that fires twice a day and an AI pipeline processing thousands of documents per hour both run on n8n, but they require very different hardware.

n8n docs say 1 vCPU and 2 GB RAM minimum. That gets you a running process, not a stable one.

n8n RAM requirements

RAM is the primary constraint. n8n runs on Node.js and holds entire workflow datasets in memory as JS objects. A single execution processing an array of 5,000 nested objects can consume 200-500 MB. Concurrent executions multiply that. The n8n process itself idles at 300-500 MB, PostgreSQL adds another 200-500 MB, and Redis adds 50-100 MB on top.

A simple way to think about it:

• 1 vCPU / 2 GB RAM — enough to launch n8n, open the UI, and run a handful of simple workflows. Expect OOM kills under any concurrent load. This is a sandbox, not a server.
• 4 GB RAM — single-instance production with moderate traffic works here, but there's no headroom for heavy JSON payloads or AI calls. Think of it as a floor, not a comfort zone.
• 8 GB RAM — comfortable single-instance production. Fits n8n + PostgreSQL + Redis on one machine. You can start testing Queue Mode with 1-2 workers.
• 16+ GB RAM — full Queue Mode: main process + 2-4 workers + PostgreSQL + Redis + Nginx, all on one box. Needed for high-concurrency setups, bulk operations, and webhook-intensive scenarios at sustained volume.

NVMe is an n8n hosting requirement for production

The write-ahead logging and vector DB queries of PostgreSQL create I/O pressure that standard SSDs cannot keep up with. Community reports consistently attribute sluggish AI agents to storage bottlenecks rather than CPU issues. If your instance feels slow and htop shows normal CPU usage, check your disk.

Which plan?

Our DevOps engineer tested n8n across the full range of is*hosting n8n VPS plans — from simple webhook-to-CRM automations to production AI pipelines with large context windows.

His take: requirements depend entirely on what your workflows actually do. A support ticket handler that processes one request per minute and a bulk ETL job scraping 10,000 records are both "n8n," but they live on different planets resource-wise.

Here's what he found:

• Start VPS (2 vCPU, 2 GB, 30 GB NVMe, from $10.19/mo) — dev, testing, solo use with simple workflows. One user, 10-20 lightweight automations on SQLite. Outgrown fast.
• Medium VPS (3 vCPU, 4 GB, 40 GB NVMe, from $21.24/mo) — minimum single-instance production. PostgreSQL runs alongside n8n in Docker, in regular mode, with 50-100 workflows and moderate traffic. Good for a small team's internal automations or for an agency running several clients on a single instance.
• Premium VPS (4 vCPU, 8 GB, 50 GB NVMe, from $31.99/mo) — recommended production. Enough RAM to run n8n + PostgreSQL + Redis comfortably and begin testing Queue Mode. Handles a team of 20-30 or a SaaS startup using n8n as its integration backend.
• Elite VPS (6 vCPU, 16 GB, 80 GB NVMe, from $47.99/mo) — full Queue Mode, webhook-intensive integrations, 1,000+ executions/day. This is n8n as critical infrastructure.
• Exclusive VPS (8 vCPU, 32 GB, 100 GB NVMe, from $71.99/mo) — enterprise, multi-worker Queue Mode, heavy AI pipelines. At this level, splitting PostgreSQL onto a separate machine may make more sense than keeping everything on one box — unless simplicity is the priority.

All plans: n8n pre-installed, KVM isolation, NVMe storage, 40+ locations.

Shared VPS servers are subject to the provider's CPU throttling, causing jitter in time-sensitive workflows.

For regulated industries (such as finance and healthcare), dedicated resources are required. KVM-based VPS fits that.

If your workload outgrows even the Exclusive tier — or you need full hardware isolation for compliance — the next step is a dedicated server. Our engineer's own production setup for high-volume pipelines runs on a dedicated machine. At that point, you're past VPS territory: the workload dictates the hardware, not the other way around.

The Database Decision

n8n ships with SQLite by default. For getting started and testing workflows, it works fine, and it's one less thing to configure on day one. And there is a gotcha.

Why SQLite breaks in production

SQLite uses file-level locking — one write at a time. When multiple webhooks fire simultaneously, you get database is locked errors.

Worse: incoming records get dropped silently. The webhook fires, n8n receives it, but the execution never hits the history. You don't know you lost data until someone asks about a missing lead.

Why teams choose PostgreSQL

If you already know you're going to production with real traffic, starting with PostgreSQL saves you the n8n migration later.

PostgreSQL gives you row-level locking, connection pooling, and point-in-time recovery without pausing n8n.

If you started on SQLite, migrating isn't terrible, but SQLite and PostgreSQL handle some data types differently, so older execution logs can throw errors mid-import. The practical fix from r/AiAutomations: prune your execution history before migrating and start fresh on PostgreSQL. You don't need months of old logs, and skipping them makes the move clean.

Our engineer skipped SQLite entirely.

Queue Mode for high volume

Redis acts as a message broker between the n8n editor and separate worker processes. Workers pull and execute independently, so a heavy workflow can't block the editor or starve other executions. One operator running 6 paying clients on a single VPS reported that Queue Mode doubled effective capacity while cutting latency 4x.

The tradeoff: you're now managing Redis, PostgreSQL, and multiple workers with DNS and firewall rules between them. A realistic threshold: if you're sustaining 50+ executions per minute or running heavy workflows that starve the main process, it's time. For a 20-workflow setup with moderate traffic, it's overkill. Don't add it until you actually need it.

SSL, Reverse Proxy, and the Webhook Problem

Lifhack: Deploying n8n on a VPS using AI assistants is a proven method, and it's the easiest way to avoid common issues.

Prerequisites: Ubuntu 22.04+ (or any Linux with Docker), Docker and Docker Compose installed, and a domain name pointed at your server's IP.

WEBHOOK_URL

The most common n8n webhook configuration mistake is also the quietest.

Without N8N_WEBHOOK_URL set explicitly, n8n generates URLs like http://localhost:5678/webhook/... — unreachable from outside the server. Every external service waiting for a callback hits a dead address, and from n8n's side, nothing looks wrong.

One agency owner lost 3 days of client leads before spotting this — because from n8n's side, nothing looked wrong.

Fix:

N8N_WEBHOOK_URL=https://your-domain.com

Set it in .env or docker-compose.yml. Pin it to your public domain.

Reverse Proxy, Nginx + Certbot

A reverse proxy handles SSL termination and blocks direct access to n8n. Nginx with Certbot is standard; Caddy is lighter but gives less control over WebSocket proxying.

Install Nginx and Certbot:

sudo apt update
sudo apt install -y nginx certbot python3-certbot-nginx

Create the site config at /etc/nginx/sites-available/n8n:

server {
    listen 80;
    server_name n8n.example.com;

    location / {
        proxy_pass http://localhost:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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_read_timeout 3600s;
        proxy_buffering off;  # required for SSE/streaming
        proxy_send_timeout 3600s;
        client_max_body_size 50M;
    }
}

The Upgrade and Connection headers are required — without them, the n8n editor's real-time UI breaks with WebSocket errors. The timeout values (3600s) prevent Nginx from killing long-running workflow executions. client_max_body_size handles large JSON payloads and file uploads.

Enable the site and test:

sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Issue an SSL certificate with Certbot:

sudo certbot --nginx -d n8n.example.com

Certbot will automatically modify the Nginx config to add SSL. Certificates renew via a systemd timer — verify it's active:

sudo systemctl status certbot.timer

One detail from the n8n docs: when running behind a reverse proxy, set N8N_PROXY_HOPS=1 in your environment. Without it, n8n can't read the real client IP from the forwarded headers, and webhook URL generation may still break.

Expose only ports 80 and 443. Lock SSH to specific IP ranges:

sudo ufw allow ssh
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

What Breaks After Month One

These are the things that get you later, after you've moved on to other work and the n8n instance is running quietly in the background.

The Encryption Key You Forgot to Save

N8N_ENCRYPTION_KEY encrypts all stored credentials — API keys, OAuth tokens, database passwords. Lose this key during a migration or container rebuild, and every credential becomes permanently unreadable. The database is intact, the workflows are intact, but nothing authenticates.

Store the key in an external vault (Vaultwarden, Bitwarden, another password manager) — anything decoupled from the n8n server.

Execution History Bloat

n8n retains every execution by default. That amounts to tens of gigabytes of high data usage over the course of several months. When the disk fills, PostgreSQL stops writing, and n8n stops responding.

Fix:

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168  # hours — 7 days

72 hours works for most teams. 168 is a safer default.

Version Updates That Break Workflows

n8n moves fast, which is great until a release breaks your workflows because a node's output schema or credential requirements have changed between versions. This happens regularly enough that the community treats it as expected behavior.

Pin your version:

image: n8nio/n8n:2.4.5  # not :latest

Update intentionally. Test in staging. Read the changelog.

HTTP Timeout for AI Calls

This one only shows up when you start integrating LLMs. n8n's default HTTP timeout is 300 seconds. Claude and GPT calls with large context windows regularly exceed that. The request works perfectly against the API directly, but fails inside n8n with a generic timeout error that tells you nothing useful.

Fix:

# In your HTTP Request nodes, set timeout to 600000 ms (10 min)
# For LLM calls, prefer native vendor nodes (Anthropic, OpenAI)
# over raw HTTP Request — they handle streaming correctly.
# Also increase max payload size for large responses:
N8N_PAYLOAD_SIZE_MAX=64  # MB

Security Defaults That Aren't Secure

n8n executes arbitrary code — Python, JavaScript, shell commands. That's the feature and the attack surface.

• Sandbox escapes

CVE-2026-1470 and CVE-2026-0863: vulnerabilities in the expression evaluation engine and Python execution nodes that allow authenticated RCE on the host. Both CVEs are patched in n8n 1.123.17+, 2.4.5+, and 2.5.1+.

Upgrade to n8n 2.0+, where Task Runners isolate code execution in a separate process by default. On older versions (1.x), switch to External mode to run code in a Docker sidecar instead of the main n8n process.

• Network isolation

Don't expose port 5678 to the public internet. Put n8n behind a VPN or an identity-aware proxy (Cloudflare Tunnels). Any HTTP Request or Code node can reach internal network addresses by default — including cloud metadata endpoints (169.254.169.254).

• Secrets management

If your .env ends up in a Git repo or shared volume, every credential is exposed. Use Vaultwarden, Doppler, or Docker secrets.

Set N8N_BLOCK_ENV_ACCESS_IN_NODE=true to prevent Code nodes from reading environment variables — including your encryption key and database credentials.

n8n Production Setup: What the Stack Looks Like

A complete n8n self-hosted setup has four components minimum:

• n8n — Docker container with persistent volumes.
• PostgreSQL — dedicated container, dedicated volume.
• Nginx/Caddy — reverse proxy, SSL termination.
• Certbot — Let's Encrypt certificate management.

For Queue Mode, add Redis and one or more worker containers.

Set up a dead man's switch. An external service (UptimeRobot, Healthchecks.io) pings an n8n webhook on a schedule. If the response stops, you get an alert. Sounds paranoid; catches the exact failure mode that Docker restart policies miss — a container that's technically running but stuck in a bad state.

Set up one error workflow per client or project, pushing failures to Slack/Telegram. Catches silent failures — Stripe signature mismatches, Google auth expiries, LLM timeouts — before they pile up for weeks unnoticed.

For server-level monitoring, our engineer uses Beszel — a lightweight, self-hosted dashboard for tracking CPU, RAM, disk, and network across machines. Simpler than Grafana + Prometheus if you don't need per-workflow metrics.

Final Thoughts

With the Community Edition, the VPS is your only recurring cost to self-host n8n.

Here's the n8n cloud vs self-hosted math: n8n Cloud Pro costs €60/mo for 10,000 executions. A self-hosted Community Edition on a Premium VPS costs $31.99/mo for unlimited executions.

Next step — get a VPS with n8n pre-installed and set up the rest of the stack.