Choosing a VPS for self-hosted n8n: RAM, CPU and sizing for your workload

n8n runs on very modest machines — that is one of self-hosting's selling points. But between the entry-level VPS that happily runs three sync workflows and the instance absorbing RAG pipelines and webhook bursts, there is real sizing work to do, and mistakes get paid for in OOM kills at 3 a.m. This guide answers the precise question: how much RAM, CPU and disk n8n actually needs depending on your usage profile, and how to pick a host. It complements our guides on the real cost of self-hosted n8n (full TCO, human time included) and installing n8n with Docker (the setup itself) — here, we only talk about the machine.

Why RAM is the limiting factor

One architectural fact explains almost all of n8n's sizing: a workflow execution loads its data into memory. Every item flowing through the workflow, every API response, every document split into chunks for a RAG pipeline lives in RAM during the execution. A workflow that fetches 10,000 rows from an API and transforms them across five nodes keeps several intermediate copies of that data in memory at once.

Binary files make it worse: by default, a 50 MB attachment traversing a workflow occupies RAM, not just disk. The N8N_DEFAULT_BINARY_DATA_MODE=filesystem variable offloads binary data to disk and noticeably relieves memory pressure — one of the first settings worth knowing, covered in our guide on handling large files in n8n.

The CPU, on the other hand, is rarely the bottleneck: a workflow spends most of its time waiting for external APIs (a CRM, an AI model, a database), and the processor sits idle during that wait. This gap between average utilization and installed capacity is a long-documented phenomenon: the study by Luiz André Barroso and Urs Hölzle, "The Case for Energy-Proportional Computing" (IEEE Computer, 2007, see on Google Scholar), showed from Google's own servers that machines spend most of their time between 10 and 50% CPU utilization — almost never at full load. An automation server is a textbook case of that profile: don't pay for vCPUs that will sit waiting for webhooks; invest in the RAM that actually stays busy.

Three profiles, three sizings

Orders of magnitude drawn from practice — adjust to your actual workflows, these are not official thresholds:

• A few simple workflows (CRM syncs, Slack notifications, RSS monitoring, small volumes): 1 to 2 vCPUs and 2 GB of RAM are enough, with PostgreSQL on the same machine. This is the profile of most freelancer and small-business instances.
• AI and RAG workflows (documents split into chunks, embeddings, agents with conversation memory, PDF or image files): aim for 2 vCPUs and 4 GB of RAM, more if several heavy workflows run in parallel. Model calls go through APIs (the compute happens at the provider), but payloads, documents and contexts all transit through your instance's memory.
• High volumes and load spikes (e-commerce webhook bursts, hundreds of simultaneous executions): past a certain point, the answer is no longer a bigger VPS but queue mode with Redis and workers — more on that below.

On disk, 20 to 40 GB comfortably covers the OS, Docker and the database — provided you prune the execution history (see the classic mistakes below).

SQLite or PostgreSQL depending on size

On a test VPS, the default SQLite works with zero configuration. As soon as the instance becomes a production link — growing execution history, serious backups, and all the more so queue mode, which requires PostgreSQL — start on PostgreSQL directly: migrating afterwards is the kind of project that gets postponed until the incident. The full docker-compose.yml is in our Docker installation guide, and the backup strategy in the PostgreSQL backup and restore guide. Just account for the fact that PostgreSQL on the same machine consumes a few hundred MB of RAM: factor it into the sizing.

Choosing the host: the criteria that matter

For a European audience, EU-based providers — OVHcloud, Hetzner, Scaleway, among others — tick the essential boxes, with entry- and mid-range VPS offers at a few euros per month (exact prices change too fast to be worth copying here). The criteria to check, in order:

• EU location and GDPR: data centers in France or Germany, operated by a European company, considerably simplify compliance when workflows process personal data — often the very reason for self-hosting, as our self-hosted vs n8n Cloud comparison details;
• Built-in snapshots and backups: being able to trigger a VPS snapshot before every n8n update is a valuable safety net — it complements, without replacing, application-level database backups;
• Upgrades without reinstalling: check that you can grow the existing VPS's RAM and CPU rather than migrating to a new machine;
• Dedicated IPv4 and clean reverse DNS: needed to expose your webhooks over HTTPS with a domain name;
• Outbound traffic: most plans include far more than an n8n workload needs, but glance at the limits if your workflows move large files around.

The classic sizing mistakes

Three failures keep coming back on undersized instances:

1. The swapping instance: RAM overflows, the system compensates on disk, and everything slows down — the editor crawls, webhooks take seconds to respond. Swap hides the problem instead of solving it: it is a signal to add RAM or lighten the workflows (process in batches, enable filesystem mode for binary data).
2. The container OOM kill: the Linux kernel kills the n8n process when memory truly runs out. The typical signature: the container restarts on its own with exit code 137, and the in-flight execution is lost. An external healthcheck and an alert, as described in our n8n instance monitoring guide, turn this silent crash into actionable information.
3. The disk filled by saved executions: by default, n8n keeps every execution's data in the database. On an active instance, that history quickly measures in gigabytes. The fix takes a few environment variables:

# Automatically prune execution history
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168            # keep 7 days (in hours)
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000  # and at most 10,000 executions

# Optional: don't store details of successful executions
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none

These settings — and the other variables relevant to sizing — are reviewed in our n8n environment variables guide. Tune retention to your real debugging needs: seven days is often plenty, and critical workflows can log what must be kept elsewhere.

Upsize the VPS or switch to queue mode?

Vertical scaling (more RAM, more vCPUs) is the right answer as long as the problem is the size of individual executions: a bigger file, a longer RAG context. It hits its limits when the problem becomes the number of simultaneous executions: in the default execution mode, everything runs in the same process, and a webhook burst or three long overlapping AI workflows fight over the same memory.

At that point, queue mode changes the architecture: a main instance receives triggers, Redis handles the queue, and workers — on the same machine or on others — absorb the load in parallel. Two modest VPS with workers then offer more resilience than a single big machine, which remains a single point of failure. Rule of thumb: if you are about to double the RAM for the second time because of concurrency (rather than payload size), that is the signal to look into queue mode.

Key takeaways

Size an n8n VPS by RAM, not CPU: 2 GB for simple workflows, 4 GB and up as soon as AI and files get involved, PostgreSQL from day one if the instance is headed for production. Pick a European host based on data location, snapshots and the ability to upgrade without reinstalling — the price, at a few euros per month, is rarely the deciding factor. Configure EXECUTIONS_DATA_PRUNE from day one, watch for swapping and exit code 137, and when concurrency rather than execution size becomes the problem, move to queue mode instead of buying an ever-bigger VPS.