What Server Do You Actually Need to Self-Host n8n? (Honest Sizing Guide)

The Question Nobody Gives a Straight Answer On

Most guides about self-hosting n8n either say "just spin up a $5 Droplet, it's fine" or "you need a proper server with 4GB RAM minimum." Both are technically correct depending on what you're doing. Neither helps you make an actual decision.

So here's the honest version.

n8n itself is lighter than people expect. At idle, with no workflows running, it typically sits between 100 and 150MB of RAM. That's it. The base process is not the problem. The problem is what happens when workflows start executing, especially if they're processing large payloads or running many times per hour.

This post walks through how to actually size your server for your situation.

What Actually Uses RAM in n8n

There are three things that consume resources in an n8n deployment.

The first is the n8n process itself. As mentioned, 100-150MB at idle. When a workflow executes, n8n loads the workflow definition, runs the nodes in sequence, and holds the execution data in memory until it's done. A simple workflow (webhook, transform, HTTP request) might add another 20-30MB briefly. A complex workflow with large JSON payloads, multiple loops, or a lot of nodes can push 200-400MB per execution.

The second is the database. n8n uses SQLite by default or PostgreSQL if you configure it. SQLite is fine for low-volume setups and adds almost nothing to your memory footprint. PostgreSQL is better for higher volume and production use, but it's a separate process eating 50-100MB by itself.

The third, and the one people miss, is concurrent executions. If your webhook gets 20 hits in 10 seconds and each execution uses 100MB of peak memory, you need 2GB just for those 20 concurrent jobs. Most solo user setups never hit this. Some production setups hit it constantly.

Concrete Sizing Recommendations

Solo user, under 50 workflow executions per day, simple payloads.

A 1GB RAM VPS works fine. You'll want to use SQLite (default) to avoid the PostgreSQL overhead. Keep execution log retention low (more on that below). Don't run other memory-intensive services on the same box.

Hetzner's CX22 (2 vCPUs, 4GB RAM, about 5 euros per month) is overkill for this case but it's the entry point that gives you comfortable headroom. The Hetzner CX11 (1 vCPU, 2GB RAM) also works well and costs about 3.29 euros per month. That's what most small setups actually need.

Small team, 100-500 executions per day, moderate payloads.

Go to 2GB RAM minimum. If you're using PostgreSQL (which you should at this volume for reliability), that's eating 80-100MB already. You want room for 3-5 concurrent executions without memory pressure. A 2-4GB server with 2 vCPUs covers this well.

DigitalOcean's Basic Droplet at $18/month (2GB RAM, 1 vCPU) works. Hetzner CX32 (4 vCPUs, 8GB RAM, about 14 euros) is a meaningful step up if you want to grow into it without thinking about this again.

Production team, 500 or more daily executions, large JSON payloads, or webhooks that need to handle traffic spikes.

4GB RAM as a floor. Queue mode enabled (covered below). PostgreSQL for the database. Run a Redis instance for the queue (adds another 30-50MB but changes how n8n handles concurrency entirely).

At this scale you're spending $25-50/month on infrastructure regardless of provider.

The Storage Problem Nobody Mentions Until It's a Crisis

Execution logs are the silent disk killer.

By default n8n stores every execution with full input and output data for every node. On a workflow that runs 200 times a day and each execution log is 50KB, that's 10MB per day, 300MB per month. Not huge. But if your workflows handle large API responses (think Airtable or HubSpot syncs with 500 rows), each execution log can be 2-5MB. Same math: 200 executions/day at 3MB each is 600MB daily, 18GB per month.

Three things to configure:

First, set EXECUTIONS_DATA_PRUNE to true in your environment. This enables automatic cleanup.

Second, set EXECUTIONS_DATA_MAX_AGE to something reasonable. We use 168 (that's 7 days in hours) on most client setups. Some teams want 30 days for debugging. More than 60 days is rarely necessary.

Third, if your workflow processes large files or API responses with many rows, add a Code node at the end of your workflow that strips the payload down before n8n logs it. Something like returning just the count and a status field instead of the full response object. Execution log size drops by 90% on those workflows.

For a fresh self-hosted setup, start with 40GB of disk. That's enough for several months at most volumes. Scale up when you can see you're going to need it.

Queue Mode vs Regular Mode

This is the part most sizing guides skip over.

Regular mode (the default) runs all workflow executions in the same process that's handling the main n8n UI and webhooks. This means a long-running execution can delay your webhook responses. On low-volume setups, it's invisible. On busier setups, it causes timeouts and weird behavior.

Queue mode separates the n8n main process (handles the UI, receives webhooks, manages the queue) from worker processes (execute workflows). You can run multiple workers. The queue is Redis.

When to use queue mode: if you're getting more than 50 concurrent webhook hits per hour, or if you have long-running workflows (more than 30 seconds) mixing with time-sensitive webhooks. Also use it if you ever plan to scale horizontally.

When to stick with regular mode: most small business setups. If your daily volume is under a few hundred executions and you're not dealing with traffic spikes, queue mode adds complexity (and a Redis instance) without a meaningful benefit.

The setup for queue mode requires: a Redis server (Hetzner CX11 handles it, or use Railway Redis at $0-5/month), and n8n started with EXECUTIONS_MODE=queue. Then you start separate worker processes with n8n worker. Not complicated but it's more infrastructure to manage.

Specific Provider Recommendations

Hetzner is the best value. EU-based, fast, reliable, affordable. For most self-hosted n8n setups, it's the first choice. The CX22 (4GB RAM, 2 vCPU, 40GB SSD, 5.09 euros/month as of early 2026) is the setup we recommend most often. The Hetzner CX11 (2GB RAM) works for solo users watching budget carefully.

The one downside: Hetzner is German infrastructure. If your data has to stay in the US or you need US-based servers for latency reasons, Hetzner still has Ashburn DC but the UI is EUR-denominated and some clients find that annoying.

Railway is the easiest to get started. You don't manage a Linux server directly. Push a Docker image, set environment variables, done. The Hobby plan is $5/month. It works for light usage. The problem is Railway's pricing scales with usage rather than a fixed tier, so a month with unusually high execution volume can cost more than expected. Good for testing and light production. Not ideal for high-volume.

DigitalOcean has better documentation than Hetzner in English and a larger community of n8n tutorials. The Basic Droplet at $12/month (2GB RAM) is solid. Their one-click app marketplace doesn't have an n8n option (as of mid-2026) so you're still doing a manual install, but their SSH setup and firewall tooling is friendly for people who don't manage servers daily.

Avoid shared hosting or cPanel-based providers for n8n. n8n needs a persistent Node.js process and typically a reverse proxy. Shared hosting environments are designed for PHP and static files. It's technically possible to get n8n running but you'll fight the environment constantly.

A Note on the n8n Cloud Option

n8n Cloud exists. It's $20/month for the Starter plan (5 active workflows) and $50/month for Pro (15 workflows). If self-hosting isn't something you want to maintain, the Cloud option is reasonable.

The reason most technical users self-host is the workflow count limits on the hosted plans. The Starter plan's 5 workflow limit gets tight quickly. Self-hosting on a $5-14/month server means unlimited workflows.

The tradeoff: you own the uptime. If the server goes down, n8n is down. You need to configure backups. You need to handle updates manually. For a business that depends on n8n workflows running reliably, that's a real operational responsibility.

A Real Example

One thing that shook some of our assumptions: a client we helped in Q4 2025 was running about 180 workflow executions per day on a Hetzner CX11 (2GB RAM). Most executions were pulling from HubSpot, transforming data, and writing to a Google Sheet. Each execution handled about 40-60 rows of JSON.

RAM usage sat at 1.1GB pretty consistently. No issues. Then they added a workflow that processed PDF attachments from emails, extracted text via an API, and pushed results to Notion. The PDF processing workflow ran 30 times per day. RAM usage jumped to 1.7GB. Still fine.

Two weeks later they enabled a Slack integration that fired on every message in 4 channels. Suddenly they had burst execution volume of 200+ jobs in a few minutes during business hours. RAM usage spiked to 1.95GB. The server started swapping. Response times on their webhook endpoints degraded noticeably.

The fix was switching to queue mode and adding a second CX11 as a worker node. Total infrastructure cost went from 3.29 euros to 6.58 euros per month. Problem solved.

The point: size for your expected peak, not your average. And build in a path to queue mode before you need it.

---

If you want us to build this for you, book a free workflow audit at airtective.com