5 Best VPS for n8n Self-Hosting

n8n runs on almost any VPS, but most cheap plans buckle once you hit 30-50 active workflows. The bottleneck is rarely CPU. n8n is a Node.js app that idles around 100-500 MB and spikes to 1-2 GB per running execution. Add Postgres for production storage and a reverse proxy for TLS. A 2 GB RAM box runs out of headroom fast.

Most production self-hosters land between $5 and $30 per month. Below $5 you’re either on shared hosting that calls itself a VPS or a 1 GB plan that swaps under load. Above $30 you’re paying for managed services or specs you won’t use.

Pick on RAM first, NVMe disk speed second. Dedicated cores help if your budget allows it but aren’t required for most workloads. The five plans below cover personal automation through high-volume webhook setups, ranked best to worst.

How to size a VPS for n8n

n8n’s own docs say memory needs supersede CPU needs. The numbers back that up. n8n idles at 100-500 MB depending on the database backend, and a single complex workflow can push another 1-2 GB during execution. Postgres adds 512 MB to 1 GB on top once you’re past a trivial workload. A 2 GB VPS that looked fine in testing starts swapping when three workflows fire at the same time.

CPU is rarely the limit. n8n isn’t compute-heavy unless you’re running heavy AI/LLM nodes locally or doing image processing inside Code nodes. For typical HTTP request and webhook handling alongside database reads, 2 vCPUs handle a lot of throughput.

Three sizing tiers cover most use cases.

• Personal or low-volume. 1-2 vCPU, 2 GB RAM, 25 GB NVMe. Hobbyists running scheduled workflows or learning n8n on side projects. Works fine if executions stay under maybe 100 per day and workflows don’t process large files.
• Small business production. 2 vCPU, 4 GB RAM, 40 GB NVMe. The realistic baseline once you’re running n8n for actual work. Handles dozens of scheduled workflows and light webhook traffic, with Postgres running on the same box.
• Heavy webhook or AI workflows. 4 vCPU, 8 GB RAM, 80 GB NVMe. For high webhook volume, frequent AI agent calls, scraping pipelines, or workflows that move large payloads. Also the sweet spot if you’re using queue mode with multiple worker containers.

Past that, you’re better off splitting components than scaling vertically. Once you cross around 50 concurrent workflow executions or your execution history starts pushing past 20 GB of Postgres data, move Postgres to its own VPS or a managed database service. The same logic applies to Redis once you turn on queue mode. Two 4 GB boxes outperform one 8 GB box for n8n at scale because you’re isolating memory and disk contention.

Top 5 VPS for n8n self-hosting

All five providers below run n8n in Docker without trouble. The differences come down to price-to-performance, data center coverage, support quality, and how much setup work you want to do yourself.

1. Hetzner Cloud (CCX13)

The CCX13 plan from Hetzner is the production sweet spot for n8n. You get 2 dedicated AMD EPYC vCPUs, 8 GB RAM, 80 GB local NVMe, and 20 TB of monthly traffic for around $15/mo. Dedicated cores matter once you’re running multiple workflows because shared CPU pools introduce steal time during peak hours, which shows up as workflow execution lag.

NVMe disk performance is genuinely strong. Independent benchmarks measure 58,000+ read IOPS on the shared CX line, and the dedicated CCX line does even better. That matters for n8n because Postgres lives on the same disk by default, and queue mode workloads hammer it hard.

The catch is no managed services and no formal uptime SLA. You’re running everything yourself. EU data centers are top-tier, but the US locations include only 1 TB of bandwidth instead of 20. Support is ticket-only and skews toward EU business hours.

If you need a smaller box first, the CX22 (2 shared vCPU, 4 GB RAM, 40 GB NVMe, 20 TB) costs $4.59/mo and works fine for personal n8n.

2. Hostinger KVM 2

Hostinger KVM 2 is the easiest path if you don’t want to spend an hour configuring Docker and Caddy yourself. You get 2 vCPU, 8 GB RAM, 100 GB NVMe, and 8 TB of bandwidth for around $8.99/mo on a long contract. It also ships with a pre-configured n8n template that handles the Docker stack and SSL setup in a few minutes.

The convenience comes with caveats. Promo pricing is the lowest tier (typically a 48-month commit) and renewals roughly double. AMD EPYC 7702P CPUs handle n8n loads cleanly, but the shared CPU pool means peak-hour throughput varies more than on a Hetzner CCX. The Kodee AI assistant inside the dashboard is genuinely useful for backup setup and basic Linux tasks if you’re not deep on the command line.

Best fit if you want minimal setup overhead and automatic SSL without paying enterprise rates. Skip it if you want true root simplicity, because the Hostinger panel layers some extra stuff on top of the VPS that you’ll occasionally need to fight.

3. DigitalOcean Premium AMD

DigitalOcean’s Premium AMD droplets are the best US-centric option for n8n. The 2 vCPU / 4 GB / 80 GB NVMe plan runs $24/mo, which is noticeably more expensive than Hetzner for similar specs. You’re paying for the ecosystem. Managed Postgres if you don’t want to run it yourself, automated snapshot backups, a marketplace 1-Click Droplet for n8n, and extensively documented platform tooling.

CPU performance is solid but disk and network benchmarks lag Hetzner’s at the same tier. That said, DigitalOcean has 13+ regions including Tokyo, Sydney, Bangalore, and São Paulo, which matters if your n8n workflows hit APIs in regions Hetzner doesn’t serve well.

The DigitalOcean ecosystem makes it easier to scale beyond a single VPS. Spaces for object storage and App Platform for adjacent services integrate with droplets cleanly. If you expect to add Redis queues or move Postgres off-box within a year, DigitalOcean reduces friction at every step.

4. Contabo Cloud VPS S

If your only constraint is the monthly bill, Contabo wins. The Cloud VPS S gives you 4 vCPU, 8 GB RAM, 200 GB SSD (NVMe optional), and 32 TB of bandwidth for around $6.99/mo. On a 12-month prepay, the European version drops to roughly €3.60. No other provider on this list matches the resources-per-dollar ratio.

The catches are real. Provisioning takes longer than competitors, sometimes hours instead of minutes. Support response times skew slow, and abuse-recycled IPs occasionally trigger immediate suspensions on fresh VPSes (community reports confirm this happens). CPU performance is fine for most n8n loads, but expect more variance than on Hetzner or DigitalOcean. The control panel is dated and split between two dashboards.

For self-managed n8n where uptime isn’t life-or-death and you want to throw spare RAM at workflow concurrency, Contabo is a legitimate pick. For anything where downtime costs money or you need fast support escalation, look elsewhere.

5. Kamatera Cloud Server

Kamatera takes a different approach. You build your VPS spec from scratch instead of picking a preset plan. Pick vCPU count, RAM, storage type, OS, and data center separately. A typical n8n production config (2 vCPU, 4 GB RAM, 50 GB SSD) runs about $22/mo. Cheaper configurations exist if you tune them precisely.

The big draw is data center coverage. 13 locations across 4 continents, including spots that Hetzner and DigitalOcean don’t cover well (Hong Kong, Dallas, Toronto, Tel Aviv). If you’re in Asia or your n8n workflows hit APIs in regions where Europe-based latency hurts, Kamatera’s footprint is the most flexible on this list.

The downside is no n8n template and a console that takes some learning. You’re configuring everything from a base Ubuntu image. Pay-as-you-go billing with hourly increments is genuinely useful for testing different specs before committing.

Last on the list because the price-to-performance ratio is weakest of the five for typical n8n workloads. Worth picking only when geographic coverage drives the decision.

Worth skipping

ScalaHosting’s managed pricing skews high once you factor in that you’re still doing all the n8n maintenance yourself. InMotion still ships SATA storage on lower tiers, which kills n8n disk performance. Bluehost VPS and shared-host VPS upsells charge more for less and rarely include NVMe at the entry tier.

The setup stack

The standard production deployment is three containers in one Docker Compose file. n8n itself plus Postgres for persistent storage, with a reverse proxy in front for TLS termination.

For n8n, pin the container version (don’t use :latest in production). Set these environment variables at minimum:

• DB_TYPE=postgresdb (the default SQLite breaks under concurrency)
• DB_POSTGRESDB_HOST matching your Postgres container’s service name (not localhost)
• N8N_HOST matching your public domain
• N8N_PROTOCOL=https
• WEBHOOK_URL matching your public URL
• N8N_BASIC_AUTH_ACTIVE=true plus user/password if you’re not fronting it with another auth layer

Postgres should use the postgres:16-alpine image. It’s small and ships with clean upgrade paths. Use named volumes for the data directory (/var/lib/postgresql/data) so backups and migrations work cleanly.

Caddy is the simplest reverse proxy choice. The full Caddyfile for an n8n instance is two lines.

n8n.example.com {
    reverse_proxy n8n:5678
}

n8n.example.com {
    reverse_proxy n8n:5678
}

Caddy handles Let’s Encrypt certificate provisioning and renewal automatically. No separate certbot setup and no cron jobs. Map ports 80 and 443 to the host and mount a caddy_data volume to persist certs across restarts.

The other reverse proxy options work fine if you have a reason to use them. Traefik is label-driven and scales well if you’re routing multiple services through one entry point. Nginx gives you the most control over rate limiting and request rewriting if you need fine-grained tuning. Cloudflare Tunnel skips port exposure entirely by establishing an outbound tunnel to Cloudflare’s edge, which is useful if your VPS is behind CGNAT or you don’t want inbound ports open at all.

The official n8n-io/n8n-hosting repo has working compose files for all of these patterns. Start there.

Proxy integration in n8n HTTP nodes

Plenty of n8n workflows hit endpoints that rate-limit by IP. Scrapers, social media posters, marketplace integrations, and APIs with strict per-IP quotas all need outbound traffic to come from somewhere other than your VPS IP. There are two ways to wire proxies into n8n.

The per-node method works for one-off needs. Inside the HTTP Request node, expand Options and fill in the Proxy field. The format is standard.

http://username:password@proxy-host:8080

http://username:password@proxy-host:8080

This takes precedence over any global proxy settings, which makes it the right choice when only specific workflows need a proxy or when different workflows need different proxies. For login flows or any workflow that ties session state to an IP, you want a static proxy so the IP holds across requests instead of rotating mid-session.

The global method applies to every HTTP Request node that doesn’t override it. Add three environment variables to your n8n container in docker-compose:

- HTTP_PROXY=http://user:pass@proxy:8080
- HTTPS_PROXY=http://user:pass@proxy:8080
- NO_PROXY=localhost,127.0.0.1,postgres

- HTTP_PROXY=http://user:pass@proxy:8080
- HTTPS_PROXY=http://user:pass@proxy:8080
- NO_PROXY=localhost,127.0.0.1,postgres

NO_PROXY is critical. Without it, n8n tries to route Postgres connections through your proxy, which breaks the whole stack. Add any internal service hostname (Postgres container, Redis, etc.) to the exclusion list.

One known issue worth flagging. LangChain and AI nodes like OpenAI and Gemini bypass the global proxy agent entirely. This is tracked in GitHub issue #10901, open since September 2024. If you’re routing AI calls through a proxy for compliance or geo reasons, set the proxy on the per-node Options field directly. Environment variables alone won’t catch those requests.

Which one to pick first

Most n8n self-hosters land at the Hetzner CCX13. It gives you dedicated cores plus 8 GB RAM, with NVMe disk speed for Postgres and queue work. Start there if you don’t have a specific reason to pick something else. Drop to the CX22 if your workload is genuinely small, or move to Contabo if budget is the hard constraint.