AI Automation

How Much RAM to Run Multiple n8n Workflows

BM BizMaC Team Aug 11, 2026 11 min read

The question I get most from people moving off Zapier or starting a serious automation setup is deceptively simple: "I want to run multiple n8n workflows, how much RAM do I need?" The honest answer is that n8n itself is lightweight, the workflows are not. A single polling workflow that checks an API every minute barely touches memory. Thirty workflows that each load a 2 MB JSON payload, run a small loop and call three webhooks will eat through a 2 GB VPS before lunch. This guide gives you real numbers for 2026, based on how n8n actually uses memory, so you size the box once and stop guessing.

Prerequisites

  • A Linux VPS running Ubuntu 24.04 LTS or Debian 12, with root or sudo access.
  • Docker and Docker Compose installed (n8n officially ships as a Docker image and that is the setup I recommend).
  • A basic understanding of what your workflows do, how many run on a schedule, and how many are webhook-triggered.

Why n8n memory usage is hard to predict

n8n is a Node.js application. The core process, the part that serves the editor UI and the REST API, idles at roughly 150 to 250 MB of RAM. That is the baseline you pay for no matter what. The variable part is the executions. Every time a workflow runs, n8n spins up a worker context that holds the incoming data, the intermediate results of each node, and any large payloads in memory until the execution finishes.

The two biggest RAM killers are large JSON payloads and the amount of data you pass between nodes. A webhook that receives a 5 MB payload, then splits it into items and runs a loop, can momentarily use 300 to 500 MB just for that single execution. If three of those run at the same time, you have already crossed 1.5 GB before n8n itself is counted. This is why I tell people to forget the "n8n needs 512 MB" advice from older blog posts. It is true for one test workflow. It is not true for a production box.

The second factor is concurrency. n8n runs executions in parallel by default. If your cron triggers stack up because a workflow takes 40 seconds and runs every 30 seconds, you get overlapping executions. Each one holds its own memory. The queue mode (using Redis) helps with throughput and crash recovery, but it does not reduce peak memory. It actually uses a bit more because Redis itself needs RAM.

Step 1 - Measuring your current n8n memory usage

Before you buy more RAM, measure what you already use. If n8n is running in Docker, the command is simple:

docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}"

This shows the live memory usage of every container. Run it while a few workflows execute and note the peak. The MEM USAGE column shows something like 1.2GiB / 3.8GiB. The first number is what n8n is actually holding right now.

For a more precise reading over time, use the built-in free -h command to see total system memory and swap usage:

free -h

The row that matters is Mem and the available column. If available drops under 200 MB while workflows run, you are near the limit. If the swap column shows heavy use, the VPS is thrashing and every execution slows down.

Verify: run docker stats again during a burst of executions. Peak usage above 80% of your total RAM means you should size up before the box becomes unstable.

Step 2 - RAM estimates for different workload sizes

These figures assume n8n runs inside Docker with a small PostgreSQL database (or SQLite for light setups), and no other heavy services on the same VPS. They are realistic starting points, not exact guarantees, because a single workflow can be tiny or can pull a 50 MB export from a CRM.

Workload profile Active workflows Executions per minute Recommended RAM
Light / testing 1 to 5 Under 5 2 GB
Small production 5 to 15 5 to 20 4 GB
Medium production 15 to 40 20 to 60 8 GB
Heavy / many large payloads 40+ 60+ or large files 16 GB

These numbers assume typical business automation: HTTP requests, data transformation, email sending, database updates, and occasional file handling. If your workflows process images, video, or very large CSV files, add 2 GB to the recommendation. A single workflow that downloads a 100 MB file and parses it will spike memory hard, and you want headroom, not a second VPS.

Step 3 - The real impact of queue mode and Redis

At a certain scale you will read that you should switch n8n to queue mode with Redis. This lets worker processes run executions separately from the main process, and it makes the setup more resilient. It also changes the RAM math. The main n8n container still uses its baseline, each worker container uses its own memory for executions, and Redis holds the queue and any execution data it is configured to cache.

A practical three-container setup, n8n main, one worker, and Redis, will use roughly 400 to 600 MB more than a single-container setup at idle. Under load, the worker takes the peak that the main process used to handle. The benefit is that you can run more executions in parallel without the editor UI freezing. The cost is RAM. For 15 to 40 active workflows, I would not bother with queue mode unless you see execution failures or UI slowdowns. A single 8 GB box handles that scale fine. Go to queue mode when you are pushing 50+ executions per minute and need reliable parallelism.

If you do enable queue mode, give Redis at least 512 MB of your RAM budget. The default Redis config is fine for n8n; you do not need to tune maxmemory unless you store a lot of execution data in Redis, which I advise against. Keep execution data in PostgreSQL and let Redis be a short-lived queue.

Step 4 - The 2 GB myth and why 4 GB is the real starting point

n8n's official docs state a minimum of 4 GB RAM for production use. I agree with that, and I would push it further. The n8n container, a PostgreSQL container, and a basic reverse proxy like Nginx or Caddy will already use 600 to 800 MB at idle. That leaves roughly 1.2 GB of usable memory on a 2 GB VPS for actual executions. A handful of busy workflows will consume that in seconds, and the box will start swapping.

For a production setup with more than five active workflows, I recommend a Linux VPS with 4 GB of RAM as the honest floor. It gives you room for the services, a few concurrent executions, and the OS page cache. If you know your workflows are light, simple API polls and database lookups, 2 GB works, but you will be monitoring memory constantly. I have run n8n on a 2 GB box; I would not do it again for anything beyond testing.

Verify your choice: after deploying, run a stress test. Trigger your five heaviest workflows at the same time and watch free -h. If available stays above 20% of total RAM, your sizing is safe.

Step 5 - Reducing RAM when you cannot upgrade immediately

If you are stuck on a smaller VPS for a while, there are real ways to cut memory use. The first is to reduce concurrency. In n8n, set the concurrency limit on the workflow settings or in the environment variable EXECUTIONS_PROCESS to limit parallel executions. This serializes heavy workflows so they do not stack up.

# docker-compose.yml snippet
services:
  n8n:
    environment:
      - EXECUTIONS_PROCESS=main
      - EXECUTIONS_MODE=regular
      - N8N_CONCURRENCY_PRODUCTION_LIMIT=5

The N8N_CONCURRENCY_PRODUCTION_LIMIT=5 setting caps concurrent executions at 5, which prevents memory spikes from overlapping runs. The trade-off is that workflows queue up instead of running in parallel, so a 40-second workflow triggered every 30 seconds will lag. For light workloads, this is acceptable.

The second lever is the database. If you use SQLite instead of PostgreSQL, you save about 150 MB of RAM. I do not recommend it for production because SQLite locks on concurrent writes, and n8n writes execution data constantly. Stick with PostgreSQL but tune it: set shared_buffers to 128 MB, which is enough for n8n, and disable query logging. The default PostgreSQL config assumes a much bigger machine than a small VPS.

The third lever is pruning execution data. By default n8n keeps execution history forever, and the database grows, which indirectly increases RAM. Set a retention policy of 7 days for successful executions and 30 days for failed ones via the environment variables EXECUTIONS_DATA_PRUNE=true, EXECUTIONS_DATA_MAX_AGE=168. This keeps the database small and the memory footprint predictable.

Troubleshooting RAM issues on an n8n VPS

The most common failure mode is the "out of memory" kill. The kernel kills the n8n process, and the container restarts, often losing the running execution. Check for it with:

dmesg | grep -i "killed process" | tail -20
journalctl -u docker | grep -i "killed" | tail -20

If you see the n8n container in the killed list, the fix is either more RAM, a concurrency limit, or both. Do not just restart and hope; the same load will kill it again.

The second common issue is the UI becoming unresponsive while workflows run. That is a sign the main process is starved because executions run in the same process. The fix is to move executions to a separate worker (EXECUTIONS_PROCESS=queue with a worker container) or reduce the concurrency limit so the UI thread stays responsive.

The third issue is swap thrashing. If free -h shows the swap column constantly in use, the VPS is spending more time swapping pages than running workflows. The only real fix is more RAM or lighter workflows. You can read more about why a VPS runs out of RAM and how to fix it if you want the deeper diagnostics.

RAM vs. other resources for multiple workflows

RAM is the first constraint, but it is not the only one. CPU matters for workflows that do heavy JSON parsing or image processing. A single vCPU handles typical API-based workflows fine. If you run data transformations on large arrays, two vCPUs feel much better. Disk I/O matters because n8n writes execution data to the database constantly. An NVMe disk makes a real difference here; a shared HDD will bottleneck the database.

The practical recommendation for a serious multi-workflow setup in 2026 is 4 vCPU, 8 GB RAM, and NVMe storage. That handles 15 to 40 active workflows with comfortable headroom. If you are just starting out and want to keep costs low, 2 vCPU and 4 GB RAM is the smallest production-safe size. You can scale up later, because n8n data is portable, and snapshots make the migration easy.

FAQ

How much RAM does a single n8n workflow use?

A single idle n8n installation uses about 150 to 250 MB for the core process. Each active execution adds roughly 50 to 300 MB depending on payload size and node complexity. A lightweight API poll workflow uses about 50 MB per execution; one processing a 5 MB JSON payload can use 300 MB or more.

Is 2 GB RAM enough for n8n?

For testing and one or two light workflows, yes. For production with more than five active workflows, no. The n8n core, a database, and a reverse proxy already consume 600 to 800 MB, leaving too little headroom for concurrent executions on a 2 GB VPS.

Does queue mode with Redis reduce n8n RAM usage?

No. Queue mode increases total memory usage because Redis and one or more worker containers add their own footprint, roughly 400 to 600 MB extra. The benefit is stable parallel execution and a responsive editor UI, not lower memory use.

How do I check how much RAM n8n is using?

Run docker stats --no-stream to see live container memory usage, or free -h for total system memory. For historical data, use docker stats with a monitoring tool like Prometheus and Grafana.

What happens when n8n runs out of RAM?

The Linux kernel kills the largest process, usually the n8n container. The container restarts, the running execution is lost, and you see "killed process" messages in dmesg. The fix is more RAM, a concurrency limit, or moving to a larger VPS with more memory.

Does the number of workflows matter or the number of executions?

Executions matter more. 50 inactive workflows use almost no RAM beyond the core process. 10 active workflows running every minute use far more than 100 workflows that trigger once a day. Size for peak concurrent executions, not the workflow count.

Related articles

多个 n8n 工作流的 RAM 需求

要运行多个 n8n 工作流，2GB 内存只适合测试，生产环境建议从 4GB 起步。实际内存取决于并发执行数、数据包大小和运行频率，而不是工作流数量。队列模式需要额外 400 到 600MB。如果内存不足，可以限制并发数、清理执行历史，或升级到更大内存的 VPS。建议用 docker stats 实测峰值，按峰值留出 20% 余量。

Note: This guide is for general reference. Every system and infrastructure has its own specifics, so test each step in a safe environment and consult a qualified engineer before applying it in production.