Self-hosting n8n on a VPS: sizing RAM for concurrent workflows

You are sold on n8n. You have your workflows designed. Now comes the question that trips up every self-hoster: how much RAM does n8n actually need on a VPS, and what happens when five workflows run at once? The official docs give you a minimum (1 GB) and a recommended (2 GB), but that number changes dramatically once you run concurrent executions, use the Redis queue mode, or connect to heavy external APIs. This guide gives you concrete RAM numbers per tier, real-world benchmarks, not guesswork, and maps them to actual VPS plans so you can provision once and forget it.

• Key takeaway: A solo dev running 2-3 sequential workflows per day can survive on 2 GB RAM. A team automating 15+ concurrent workflows needs 8 GB, and the Redis queue mode adds roughly 200 MB per node.
• Key takeaway: The n8n main process itself rarely exceeds 300 MB. The RAM eater is each workflow execution, roughly 50-120 MB per active execution depending on the nodes involved.
• Key takeaway: If your workflows hit external APIs (HTTP Request nodes, Webhook triggers, database lookups), execution memory spikes because the system waits on I/O. Budget 80 MB per concurrent execution for API-heavy workflows.
• Key takeaway: Redis queue mode separates the orchestrator from workers. This reduces peak memory on a single VPS but requires you to size both the main process and the worker independently.

n8n的内存需求取决于并发工作流数量，按档位选型即可。

n8n memory needs follow the number of concurrent workflows, so pick the plan tier that matches.

Why RAM Is the Bottleneck for Self-Hosted n8n

n8n is a Node.js application. Like any Node.js process, it has a single-threaded event loop and relies on asynchronous callbacks to handle concurrency. The main process itself is lightweight, a freshly started n8n instance with no workflows loaded sits at around 150-200 MB resident memory. The problem starts when you enable concurrent executions. Each workflow execution spawns its own sub-process or thread inside the runtime. n8n uses a worker pool (default size: 5) to run executions. If you set EXECUTIONS_DATA_PRUNE to true (which you should), the execution data is cleaned up after a configurable timeout, but the memory is not freed instantly, the garbage collector runs on its own schedule.

Where does the RAM actually go? Three places: the n8n main process, each running execution (holding the current state of all nodes in the workflow), and the database (SQLite, PostgreSQL, or the default). SQLite is fine for low-traffic solo setups but struggles under concurrent writes. If you swap to PostgreSQL for reliability, the database engine itself wants another 200-500 MB. The conclusion: RAM is the single most important factor for n8n performance on a VPS because CPU usage is low for most workflows (unless you run heavy JSON transformations or image processing), and disk I/O is mitigated by NVMe storage. Get the RAM wrong, and your workflows start failing with out-of-memory (OOM) errors, the Node.js killer.

The Real RAM Numbers: Solo to Team

These numbers come from running n8n on a handful of VPS instances over several months, using workflows of average complexity (HTTP requests, Slack notifications, database lookups, a bit of data transformation). Yours may differ, but they serve as a reliable baseline.

The 2 GB tier is the starting point. It works for a single developer running 2-3 workflows sequentially with SQLite. Do not expect to run a webhook-triggered flow every 10 seconds, you will see OOMs. A 4 GB VPS is the sweet spot for a small team that does not need Redis. With the default worker pool (5), you can run 5-8 concurrent executions without hitting swap. The 8 GB tier unlocks the Redis queue mode, which lets you decouple the main n8n process from worker processes. At 16 GB, you can run multiple workers on the same VPS and handle a serious production load.

Mapping RAM to VPS Plans: What to Look For

When you rent a n8n VPS, you are looking for a few specific things beyond the RAM number. First, the storage must be NVMe, n8n writes execution data to disk frequently, and NVMe handles the I/O load without slowing down the Node.js event loop. Second, you need full root access because n8n sometimes requires system-level configuration (systemd service, reverse proxy, firewall rules). Third, a dedicated IPv4 in the Vietnam range matters if your workflows touch Vietnamese services: banking APIs, local SMS gateways, or government portals that only accept connections from domestic IPs.

A 2 GB VPS, like the VNLite plan (1 vCPU, 20 GB NVMe), is the entry point. It runs n8n + SQLite comfortably for one user. At 4 GB (VNx1, 2 vCPU, 50 GB NVMe), you add PostgreSQL and a few more concurrent workflows. The 8 GB plan (VNx2, 4 vCPU, 80 GB NVMe) hits the point where you can run Redis queue mode and your workflows stop failing under peak load. Beyond that, 16 GB (VNx4, 8 vCPU, 100 GB NVMe) supports a small team running 20+ workflows. The Vietnam location gives you low-latency routing to domestic endpoints, VNPT, Viettel, FPT Telecom, and CMC Telecom, without crossing international transit. It is local infrastructure for work that touches Vietnam. It is not a fast pipe into another country; any hop leaving Vietnam crosses international transit, and your own domestic network on your side determines the rest.

The Redis Queue Mode: When and How to Size It

n8n defaults to direct execution: the main process runs all workflows inline. This works until you have more than a handful of concurrent executions, because the main process bottlenecks on a single thread. Redis queue mode solves this by pushing execution requests into a Redis list, and one or more worker processes pull jobs from that queue. The main process acts only as an orchestrator, it does not execute anything. Workers handle the actual work.

Redis itself is tiny, a bare Redis instance uses about 1-2 MB of RAM for the connection overhead, plus whatever data is queued. The real memory cost is the worker processes. Each worker is a separate Node.js instance. A typical worker process uses 150-250 MB of resident memory. If you run two workers on an 8 GB VPS, budget 300-500 MB for Redis + workers combined, leaving the rest for the main process (still lightweight around 200 MB) and the PostgreSQL database. The gain is that workers can be killed and restarted independently, and you can scale horizontally by adding more VPS with workers. But for a single-VPS deployment, the 8 GB tier is where Redis queue mode becomes practical, below that, the overhead of extra Node.js processes eats into the headroom you need for concurrent executions.

Database Choice: SQLite vs PostgreSQL and RAM Impact

n8n ships with SQLite as the default database. For a single-user setup with a handful of workflows, SQLite is fine. But SQLite holds a write lock during each execution save. When you have concurrent executions, you get SQLITE_BUSY errors. The fix is to switch to PostgreSQL, which handles concurrent writes gracefully. The cost is RAM: PostgreSQL, even with minimal configuration, uses 100-200 MB for shared buffers plus room for connection pools. A reasonable PostgreSQL config for a 4 GB VPS with n8n allocates 256 MB shared_buffers and 128 MB work_mem. That sounds small, but combined with n8n's own memory needs, it creeps into the "don't run anything else on this VPS" territory. If your VPS is 2 GB and you install PostgreSQL alongside n8n, you end up with about 1.2 GB free for n8n, enough for 2-3 concurrent workflows. At 4 GB, you have about 3 GB free for n8n after PostgreSQL. At 8 GB, you stop worrying about the database.

Real-World Scenario: A Three-Workflow Solo Setup

Let us ground this in a concrete case. You are a freelance developer. You run three workflows: (1) a webhook that receives a form submission and saves it to a Google Sheet, (2) a daily cron that checks an API for new orders and sends a Slack notification, and (3) a webhook that triggers on a payment event and creates an invoice in a CRM. None of these run more than one execution at a time. You use SQLite. Your n8n process sits at 180 MB idle. Each execution peaks at 70 MB. Swap is not touched. A 2 GB VPS with 1 vCPU is perfectly fine. You have room for the OS (about 400 MB), n8n, and SQLite. If you add a fourth workflow that does image processing via a shell command, the execution memory jumps to 150 MB, and the 2 GB tier starts feeling tight. That is where you step up to 4 GB.

When You Hit the Ceiling: Symptoms and Diagnostics

You will know you undersized the VPS before you see the OOM killer message. First sign: n8n webhooks start returning 502 or timeout errors. Second: the n8n UI becomes sluggish, workflow lists take seconds to load. Third: journalctl -u n8n shows FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory. The fix is not just to add swap, swap on an NVMe disk makes things slower but does not fix the OOM because Node.js respects a configured heap limit (--max-old-space-size). On a 2 GB VPS, set NODE_OPTIONS="--max-old-space-size=1024" to cap Node.js heap at 1 GB, keeping 1 GB for the OS and database. If you still see OOMs, you need a larger VPS.

To monitor: run htop and look at the RES column for the n8n process. It should stay below 70% of your total RAM during peak load. If it exceeds 80%, add more RAM or reduce the execution concurrency (EXECUTIONS_TIMEOUT and N8N_EXECUTATIONS_PROCESS_LIMIT environment variables).

FAQ

Related articles

• Self-hosting n8n for workflow automation on a VPS
• n8n vs Zapier at scale: the self-hosting break-even point
• Backing up n8n workflows and credentials properly
• Running n8n without Docker knowledge