n8n System Requirements: How Much RAM and CPU You Really Need

n8n itself is light: a single instance running a handful of scheduled workflows typically fits comfortably on 1 vCPU and 2 GB of RAM, PostgreSQL included. What pushes the requirements up is not how many workflows you have, but how much data each execution carries and how many executions run at the same time. Size for your peak concurrency and your largest payload, then keep disk usage in check with execution pruning.

What actually consumes RAM and CPU in n8n

• Concurrent executions. Every running execution keeps its items in memory. Ten workflows firing at once need roughly ten times the working memory of one.

• Payload size. n8n processes a node's whole output as a list of items, and an execution keeps each node's output while it runs. A workflow that pulls tens of thousands of rows from an API or a spreadsheet can hold several copies of that data in memory before it finishes.

• Binary data. PDFs, images and attachments are much larger than JSON. Depending on your version and settings, n8n may keep them in memory unless you switch binary data to filesystem mode.

• Code nodes. JavaScript and Python Code nodes run your own logic, and in recent versions they execute in separate task runner processes. Loops over large arrays and heavy libraries show up quickly in memory and CPU.

• AI nodes. When an AI Agent node calls a hosted model API, the heavy compute happens at the provider, so CPU stays low. Memory still grows with long conversation histories, document loaders, text splitting and vector store operations, and long model calls keep executions open longer, which raises concurrency.

• Webhook volume. Each webhook call is cheap, but bursts turn into many simultaneous executions, and that is where small servers run out of headroom.

• PostgreSQL. The database needs its own share of RAM for caching, and it does the writing of every saved execution.

Why one fast core matters more than many slow ones

n8n runs on Node.js, whose main event loop executes JavaScript on one thread. A single n8n process therefore leans heavily on one core, even on an 8-core server. Extra cores still help: PostgreSQL, task runners, a reverse proxy and the operating system use them, and in queue mode each worker process gets its own. But if you see one core pinned at 100% while the others idle, adding vCPUs to a single-process setup will not fix it; spreading work across workers will.

SQLite or PostgreSQL

Out of the box n8n stores everything in a SQLite file inside its data folder. That is fine for testing and light personal use. For anything you depend on, use PostgreSQL: it handles concurrent writes better, it is easier to back up and tune, and n8n's queue mode is designed around it rather than SQLite. Switching is a matter of environment variables:

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=change-me

Our production guide to self-hosting n8n walks through the full Docker setup with PostgreSQL and HTTPS.

Disk: execution data and pruning

Most disk growth in n8n comes from saved executions. Every run can store the input and output of each node, so a busy instance that keeps everything can grow its database by gigabytes. Pruning is the fix, and recent versions enable it by default; check your values rather than assuming:

# execution history: keep it bounded
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168            # hours to keep (default is 336 = 14 days)
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000  # cap on stored executions
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none   # keep only failed runs in full
EXECUTIONS_DATA_SAVE_ON_ERROR=all

Two details catch people out. First, PostgreSQL reuses space freed by deleted rows, but the database files do not shrink on their own; only VACUUM FULL returns space to the operating system, and it locks the table while it runs. Second, logs, Docker images and local backups also live on that disk. To see where space is going:

SELECT pg_size_pretty(pg_database_size('n8n'));
SELECT pg_size_pretty(pg_total_relation_size('execution_data'));

Fast NVMe storage helps here, because saving and pruning executions is a steady stream of small database writes.

Settings that protect a small server

NODE_OPTIONS=--max-old-space-size=3072     # heap limit in MB, below the RAM you have
N8N_CONCURRENCY_PRODUCTION_LIMIT=10         # cap parallel production executions (regular mode)
N8N_DEFAULT_BINARY_DATA_MODE=filesystem     # keep files on disk, not in memory

• Set the Node.js heap limit below the RAM actually available, leaving room for PostgreSQL and the operating system.

• Use a concurrency limit so a burst of webhooks queues up instead of exhausting memory.

• Process large datasets in batches with the Loop Over Items node, and move the heavy part into a sub-workflow; memory used by a sub-workflow can be released when it finishes.

• Return only the fields you need from HTTP Request and database nodes instead of whole records.

Variable names and defaults change between releases, so check the environment variable reference in the n8n docs for your version.

Sizing tiers by workload

These are starting points, not guarantees; your own payloads decide the final answer. They map onto plans that run from 1 vCPU / 2 GB up to 8 vCPU / 32 GB.

Personal and learning

A few scheduled workflows, small JSON payloads, no file processing. The entry size of 1 vCPU and 2 GB RAM with PostgreSQL is usually enough.

Small team automation

Dozens of workflows syncing CRM, email, forms and spreadsheets, some webhooks, occasional attachments. Something in the range of 2 to 4 vCPU and 4 to 8 GB RAM gives n8n and PostgreSQL room to breathe.

Heavy webhooks, files or AI agents

Bursty inbound traffic, PDF or image handling, AI agents with memory and retrieval. Prioritize RAM, think 8 to 16 GB with 4 or more vCPU, and use concurrency limits.

Many parallel, business-critical workflows

Sustained high volume where one stuck execution must not slow the rest. This is where queue mode with Redis and separate worker processes pays off, on a server toward the top of the range, up to 8 vCPU and 32 GB.

If you are still weighing a managed n8n subscription against your own server, our n8n cloud vs self-hosted cost comparison covers the execution-based pricing side.

How to measure before you upgrade

docker stats --no-stream                 # live CPU and memory per container
free -h && df -h                         # RAM and disk on the host
docker compose logs n8n | grep -i "memory"

Check usage during your busiest hour, not at night. In the n8n UI, sort executions by duration to find the slow ones, and open them to see which node holds the most items. Messages such as "n8n may have run out of memory" on a failed execution, or "JavaScript heap out of memory" in the logs, are direct evidence.

Signs you need to move up

• Executions fail with memory errors or the container restarts under load.

• Swap usage climbs and stays high during peak hours.

• The editor becomes slow to open large executions or save workflows.

• Webhook responses slow down when several workflows run together.

• One CPU core sits at 100% for long stretches: a sign for queue mode, not just a bigger server.

• Disk usage keeps growing even with pruning enabled.

n8n needs a server where it can run as a long-lived process, which rules out classic shared hosting; our overview of types of web hosting explains where VPS and app-specific servers fit.

Frequently asked questions

Can n8n run on 1 GB of RAM?

It can start, and it may be enough for testing with SQLite. With PostgreSQL, the operating system and real workflows, 2 GB is a more realistic minimum.

Does n8n need a GPU?

No. n8n orchestrates work and calls model APIs over HTTP. A GPU only matters if you also run a local model on the same machine, which is better kept on separate hardware.

Is SQLite good enough for production?

For a light personal instance it works. For team or business use, PostgreSQL is the safer choice for concurrency, backups and a later move to queue mode.

How much disk space does n8n need?

It depends on how many executions you save and for how long. Enable pruning, save only failed executions in full if you can, and watch the database size for a few weeks.

Running n8n on IM HOST

IM HOST n8n Hosting gives you your own n8n on a dedicated NVMe KVM server, with the latest n8n and PostgreSQL installed, an HTTPS address with free SSL, full root and free daily backups, ready in about 15 minutes. Five plans run from 1 vCPU / 2 GB to 8 vCPU / 32 GB with unlimited workflows and executions, and queue mode with Redis workers is available on Pro and above. Servers are available in Germany, Poland, the UK, the USA and Egypt; see the data centers page for current stock.