How much RAM and CPU do you need to self-host n8n?

Short answer Heuristic — test it

n8n publishes no minimum RAM or CPU table. An execution is one workflow run. Size depends on concurrency (runs at the same time), payload, workflow shape, and SQLite on one instance versus queue mode (worker processes, Postgres, and Redis). The docs publish no cores-per-execution figure. Heuristic to test: light single-instance work starts near the 1 GB class and moves toward 4 GB as files, Code nodes, or concurrency grow. Use the self-test on this page.

This page answers how big a server to start with. Best n8n hosting answers which kind of host suits you. Plan figures below are copied from prices.json. A dash means that field is not verified.

Why executions per month is the wrong question on its own

An execution is one run of a workflow. Concurrency is how many of those runs are in progress at the same time. Executions per month is the total. It does not say whether they arrive one by one or in a burst.

Will a 1 GB or 4 GB VPS run n8n for 10,000 executions a month?

Not from the monthly total alone. Illustrative arithmetic, not a benchmark: 10,000 divided by 30 days and then by 24 hours is about 14 executions an hour if they are spread evenly. The same 10,000 arriving as webhook bursts can be many at once. Those are different sizing problems. Concurrency, payload size, and workflow complexity decide. The labelled classes further down are a Heuristic — test it, and the self-test is how you check them. What a class costs at renewal, including where renewal is unknown, is on what n8n costs at 2,500, 10,000, and 50,000 executions a month. That page does not turn this heuristic into a capacity claim.

Production executions are the ones started by a webhook or another trigger. Manual executions are separate: n8n copies data for the editor, which uses more memory (fix memory issues). A concurrency cap, when you set one, applies to production executions only (control concurrency).

What actually uses RAM and CPU in n8n

n8n does not restrict how much data each node can fetch and process. An execution runs out of memory when it needs more than the instance has. The same page names the drivers:

• Amount of JSON data.
• Size of binary data. By default n8n keeps files in memory, which can crash a run that handles large files (handle binary data).
• Number of nodes in the workflow.
• Code nodes, and the older Function node, which can increase memory use significantly.
• Manual executions, because n8n copies data for the frontend.
• Other workflows running at the same time.

Saved execution history is a different pressure. It grows the database and disk, according to your retention settings (manage execution data). It is not the same thing as the RAM a live execution needs. This site does not quote a GB-per-execution figure. None is published, and it depends on the payload.

CPU stays qualitative. Pressure rises when many executions run at once and when nodes do heavy computation. n8n's docs do not publish a cores-per-execution figure, so this page does not invent one. Their performance page says performance depends on workflow type, the resources available, and scaling configuration, and it points you at measuring your own instance. That page is a benchmark harness, not a minimum-spec table. This guide does not turn it into one.

Single instance or queue mode, before you pick a size

Pick the layout first. The size question is different for one process than it is for a main instance, workers, Postgres, and Redis.

Single instance and SQLite

SQLite is the default. It stores credentials, workflows, and past executions in ~/.n8n/database.sqlite, and it suits development and a small single instance (choose n8n's database). In regular mode, n8n does not limit concurrent production executions by default, which can thrash the event loop. Set N8N_CONCURRENCY_PRODUCTION_LIMIT to cap production runs and queue the rest, first in, first out (control concurrency). That cap is a configuration change, not a bigger VPS. The docs' example value is not a recommendation, and concurrency control is off until you set it.

When does n8n need Postgres and Redis instead of SQLite?

Use SQLite for a small single instance. Use Postgres once you need queue mode, more than one worker, or production headroom. That split is a mode requirement from the database docs and the queue-mode docs, not a RAM benchmark. Postgres is configured with DB_TYPE=postgresdb and the DB_POSTGRESDB_* variables. As of the database page's July 2026 note, re-checked on Oct 17, 2026, n8n supports PostgreSQL 17 and 18, plus 16 for compatibility.

Heuristic — test it: any claim that Postgres itself needs a specific extra amount of RAM or CPU. The docs linked above do not publish one. In a single-VPS queue-mode setup, Postgres and Redis are two more always-on services on the same box. That is the layout, not a measured overhead.

Queue mode

A worker is a separate n8n process that runs executions. In queue mode (EXECUTIONS_MODE=queue) one main instance receives triggers, Redis brokers the queue, workers run the jobs, and a shared database stores the data (enable queue mode). You scale by adding or removing workers. Queue mode is what n8n's scaling overview points to when you have a large number of users, workflows, or executions.

Running queue mode with SQLite isn't recommended. A distributed setup over SQLite isn't supported. Documented reasons to move to queue mode are: you need to scale workers, you need to handle many executions at once, or you would otherwise be stretching SQLite into that distributed setup. Heuristic — test it: a monthly execution threshold for the switch. This page does not give one.

How many workers, and what concurrency, on a given amount of RAM?

There is no workers-per-GB number in the docs, so this page does not publish one. Worker parallelism uses the --concurrency flag. It defaults to 10. n8n recommends 5 or higher per worker. Very low concurrency across many workers can exhaust the database connection pool (enable queue mode). In queue mode, N8N_CONCURRENCY_PRODUCTION_LIMIT set to a value other than -1 overrides that flag (control concurrency). How many workers fit on a box is a Heuristic — test it.

The one memory figure the docs do publish is about Redis, not about n8n's own RAM. In queue mode, a large webhook response sits in Redis while it is in flight. N8N_WEBHOOK_RESPONSE_RELAY_SIZE_MAX defaults to 64 (MiB). Budget about 1.5 times that value in Redis memory for each response in flight (enable queue mode, queue-mode environment variables). That is a Redis sizing note for responses in flight. It is not an n8n RAM requirement. Offload (N8N_WEBHOOK_RESPONSE_RELAY_OFFLOAD_ENABLED, default false) needs a binary-data mode that stores data and storage every instance can read.

Sizing by workload Heuristic — test it

Every starting class in this table is a heuristic to test, not a benchmark. The example plans are the only ones whose RAM and vCPU are non-null in the dataset. Order inside a class follows dataset order. Affiliate status is not an input. There is no verified 2 GB plan today, so the next verified step after 1 GB is the 4 GB class. This page does not invent a 2 GB plan.

Is 512 MB or 1 GB enough for n8n, and what breaks first?

The smallest verified plan is DigitalOcean Basic Droplet 512 MiB (1 vCPU, 512 MB RAM, 10 GB disk, 500 GiB bandwidth; checked Oct 19, 2026). The verified 1 GB class is DigitalOcean Basic Droplet 1 GiB (1 vCPU, 1 GB RAM, 25 GB disk, 1,000 GiB bandwidth; checked Oct 19, 2026), Hetzner Cloud CPX02 (1 vCPU, 1 GB RAM, 20 GB NVMe, 20 TB (EU locations) bandwidth; checked Oct 19, 2026), Vultr Cloud Compute 1 GB (Regular) (1 vCPU, 1 GB RAM, 25 GB SSD, 1024 GB bandwidth; checked Oct 19, 2026), Linode (Akamai) Nanode 1GB (1 vCPU, 1 GB RAM, 25 GB disk, 1000 GB bandwidth; checked Oct 19, 2026), and Sliplane Starter (1 vCPU, 1 GB RAM, 20 GB disk; checked Oct 19, 2026). Heuristic — test it: treat the smallest verified plan above as the dataset minimum, and as the most likely of these to hit the documented memory limits once files or Code nodes show up. What breaks first is those drivers: JSON size, in-memory files, node count, Code nodes, manual runs, and other workflows at the same time. There is no published executions-per-GB failure point. This site has not run that test.

Free n8n hosting is a fair place to learn, with the limits on that page. Oracle Cloud and Render are in this dataset, and their RAM and CPU are not verified, so they are not examples in the table above. Cheapest way to host n8n ranks by price. Use it for the cheapest adequate plan, not the cheapest absolute price. Of the verified-spec plans, DigitalOcean Basic Droplet 512 MiB at $4/mo, Vultr Cloud Compute 1 GB (Regular) at $5/mo, Linode (Akamai) Nanode 1GB at $5/mo, and OVHcloud VPS-1 (2027) at $4.54/mo (12-month upfront) · $5.35/mo no commitment are also in the US-dollar set at $5/mo or less on the first-term price. Euro prices are not converted, so a euro plan is not added to that set. See n8n hosting under $5.

Prices for the verified-spec plans

First-term and renewal prices are rendered from the same dataset as the rest of the site. n8n hosting prices — October 2026 is the dated price citation. Monthly price snapshots lists every frozen month. A plan note under a price is the note stored for that plan.

Disclosure: Some host links below are affiliate links. We may earn a commission if you sign up, at no extra cost to you. Prices and order are not affected.

Once you know your size class, see what it costs at renewal for an execution volume.

Plans whose specs we have not verified (so we don't tier them)

7 plans are omitted from the tiers because RAM or vCPU is null. Nothing below is filled in from a plan name or a marketing page. How we check prices is the rule.

• Hostinger Managed n8n: vCPU —, RAM —, storage —. Checked Oct 17, 2026. The provider sizes this plan. This dataset has no RAM or vCPU to assign. Specs and backups are not verified, so they are not listed.
• n8n Cloud Starter (annual): vCPU —, RAM —, storage —. Price checked Oct 19, 2026. Specs checked Oct 17, 2026. The provider sizes this plan. This dataset has no RAM or vCPU to assign. n8n Cloud sizing is an execution-allowance question, not a RAM question. This page does not quote allowances.
• n8n Cloud Pro (annual): vCPU —, RAM —, storage —. Price checked Oct 19, 2026. Specs checked Oct 17, 2026. The provider sizes this plan. This dataset has no RAM or vCPU to assign. n8n Cloud sizing is an execution-allowance question, not a RAM question. This page does not quote allowances.
• Elestio Managed n8n (from): vCPU —, RAM —, storage —. Checked Oct 19, 2026. The provider sizes this plan. This dataset has no RAM or vCPU to assign.
• Render Hobby: vCPU —, RAM —, storage —. Checked Oct 16, 2026. Usage-based billing. Not a fixed-spec VPS, and this dataset has no RAM or vCPU to assign.
• Railway Hobby: vCPU —, RAM —, storage —. Checked Oct 19, 2026. Usage-based billing. Not a fixed-spec VPS, and this dataset has no RAM or vCPU to assign.
• Oracle Cloud Always Free: vCPU —, RAM —, storage —. Price checked Oct 16, 2026. Specs checked Oct 17, 2026.

Compare head-to-head

• DigitalOcean vs Vultr for n8n
• Hetzner vs Contabo for n8n
• Hostinger vs Contabo for n8n
• Hostinger vs Hetzner for n8n
• n8n Cloud vs self-hosted

The Hetzner comparisons take Hetzner's price and specs from the price table. This list is only the comparison pages that exist.

Storage, kept separate from RAM

Execution history is a retention setting. Pruning is on by default. Executions are pruned once they are older than EXECUTIONS_DATA_MAX_AGE (default 336 hours, which is 14 days) or once the count passes EXECUTIONS_DATA_PRUNE_MAX_COUNT (default 10,000), oldest first. Executions that are new, running, waiting, or annotated are left out, and a one-hour hard-delete buffer (EXECUTIONS_DATA_HARD_DELETE_BUFFER) keeps recent data while you are debugging (manage execution data). On SQLite, pruned space is reused rather than handed back to the disk until you vacuum.

Binary files are in memory unless you move them. On one instance, N8N_DEFAULT_BINARY_DATA_MODE=filesystem writes them to disk. In queue mode, switch that to database. Filesystem mode is not supported with queue mode (handle binary data). The queue-mode page also says you can persist binary data to S3. Webhook-response offload is a separate switch: it can use filesystem, database, S3, or Azure storage that every instance can read, and n8n does not recommend filesystem for that offload because every instance has to mount the same disk (enable queue mode). Files in memory are a RAM risk. Files on disk are a storage and IOPS question.

Verified storage on tiered plans runs from 10 GB (DigitalOcean Basic Droplet 512 MiB (1 vCPU, 512 MB RAM, 10 GB disk, 500 GiB bandwidth; checked Oct 19, 2026)) to 200 GB (Hostinger KVM 4 (4 vCPU, 16 GB RAM, 200 GB NVMe, 16 TB bandwidth; specs checked Oct 17, 2026)). No other disk size is quoted here. Disk kind is printed only where the dataset has it. There is no GB-per-execution conversion.

Fix it before you upsize it

For a lot of failed runs the next step is the workflow, not a larger VPS. Each item is from n8n's docs:

• Split large fetches into smaller chunks. The memory docs' example is 200 rows per execution instead of 10,000 (fix memory issues).
• Split the workflow into sub-workflows that return limited data to the parent (fix memory issues).
• Avoid the Code node where you can, and avoid manual executions on large data (fix memory issues).
• Move binary data out of memory (handle binary data).
• Prune execution history instead of keeping every payload (manage execution data).
• Cap production concurrency before you buy CPU (control concurrency).
• For a JavaScript heap error, raise the V8 old-space limit with NODE_OPTIONS=--max-old-space-size=SIZE (fix memory issues).

What to do when you outgrow the box

n8n's scaling docs give three directions: add workers in queue mode, give the instance more resources, or move execution data and binary data to external storage (scaling, enable queue mode). Which one is cheaper is a cost question, not a second sizing table.

Once you know your size class, what n8n costs at 2,500, 10,000, and 50,000 executions a month prices that class at renewal. The server class should be the one this heuristic plus the self-test lands on. Executions per month to size stays a heuristic to test. This sizing page still does not quote n8n Cloud execution allowances. For your own numbers, the renewal-aware calculator accepts that handoff.

How to test a size Heuristic — test it

This is a test protocol, not a benchmark. This site has not published pass/fail thresholds, and n8n's performance page is not one either.

1. Run your heaviest real workflow: the largest payload, the most Code nodes, and real binary files if you use them.
2. Run it at the peak concurrency you actually expect, on the size you are considering.
3. Watch for the failures the docs describe: out-of-memory and JavaScript heap errors (fix memory issues), and an event loop that thrashes when production concurrency is uncapped (control concurrency).
4. Check execution history and retention (manage execution data). A full disk is not a RAM result.
5. If it fails, apply fix it before you upsize it, then test again. Move up one class only if it still fails.

What you can observe: the process restarting, executions failing, and swap in use. What this page will not tell you is a safe RAM percentage or an executions-per-GB score. Those would be benchmark results, and we have not measured them.

FAQ

Is 1 GB enough for n8n?

Heuristic to test, not a measured minimum. A 1 GB class plan is a starting point for light single-instance work with small JSON and few Code nodes. What breaks first is documented: n8n does not restrict how much data a node can fetch, and an execution runs out of memory when it needs more than the instance has. The drivers are JSON size, binary data, node count, Code or Function nodes, manual executions (n8n copies data for the frontend), and other workflows running at the same time. Smallest verified plan: DigitalOcean Basic Droplet 512 MiB (1 vCPU, 512 MB RAM, 10 GB disk, 500 GiB bandwidth; checked Oct 19, 2026). Verified 1 GB plans: DigitalOcean Basic Droplet 1 GiB (1 vCPU, 1 GB RAM, 25 GB disk, 1,000 GiB bandwidth; checked Oct 19, 2026); Hetzner Cloud CPX02 (1 vCPU, 1 GB RAM, 20 GB NVMe, 20 TB (EU locations) bandwidth; checked Oct 19, 2026); Vultr Cloud Compute 1 GB (Regular) (1 vCPU, 1 GB RAM, 25 GB SSD, 1024 GB bandwidth; checked Oct 19, 2026); Linode (Akamai) Nanode 1GB (1 vCPU, 1 GB RAM, 25 GB disk, 1000 GB bandwidth; checked Oct 19, 2026); Sliplane Starter (1 vCPU, 1 GB RAM, 20 GB disk; checked Oct 19, 2026). The dataset has no verified 2 GB plan. Verified 4 GB plans: Hostinger KVM 1 (1 vCPU, 4 GB RAM, 50 GB NVMe, 4 TB bandwidth; specs checked Oct 17, 2026); OVHcloud VPS-1 (2027) (2 vCore, 4 GB RAM, 40 GB NVMe; checked Oct 17, 2026); netcup VPS Lite 1 G12.5s (2 vCore, 4 GB RAM, 80 GB SSD; checked Oct 19, 2026). Verified plans at 8 GB or more: Hostinger KVM 2 (2 vCPU, 8 GB RAM, 100 GB NVMe, 8 TB bandwidth; specs checked Oct 17, 2026); Hostinger KVM 4 (4 vCPU, 16 GB RAM, 200 GB NVMe, 16 TB bandwidth; specs checked Oct 17, 2026); Contabo Cloud VPS 4 (4 vCPU, 8 GB RAM, 100 GB SSD, unlimited traffic, 200 Mbit/s, incoming unmetered, fair-use; specs checked Oct 17, 2026).

Will 4 GB run 10,000 executions a month?

Monthly executions alone cannot answer that. Ten thousand executions spread across a month are a different load from ten thousand arriving together: concurrency, payload size, and workflow complexity decide. Heuristic to test, not a benchmark: the verified 4 GB class is a candidate for steady small-team production on one box, not a measured capacity for 10,000 executions. Verified 4 GB plans: Hostinger KVM 1 (1 vCPU, 4 GB RAM, 50 GB NVMe, 4 TB bandwidth; specs checked Oct 17, 2026); OVHcloud VPS-1 (2027) (2 vCore, 4 GB RAM, 40 GB NVMe; checked Oct 17, 2026); netcup VPS Lite 1 G12.5s (2 vCore, 4 GB RAM, 80 GB SSD; checked Oct 19, 2026). The dataset has no verified 2 GB plan. Run the self-test on this page. n8n's docs do not publish an executions-per-GB figure.

SQLite or Postgres for n8n?

SQLite is the default and suits development and a small single instance. The database file is ~/.n8n/database.sqlite. PostgreSQL is the production path: set DB_TYPE=postgresdb and the DB_POSTGRESDB_* variables. n8n's database docs, as of their July 2026 note (re-checked with the sizing sources on this page), support PostgreSQL 17 and 18, plus 16 for compatibility. Queue mode with SQLite isn't recommended, and a distributed setup over SQLite isn't supported. A specific extra RAM or CPU figure for Postgres itself is a heuristic to test: the docs do not publish one. On a single VPS, Postgres and Redis are two more always-on services sharing the box. That is the queue-mode layout, not a benchmark.

When do I need queue mode?

Queue mode is one main instance plus worker instances, with Redis as the broker and a shared database. You need it when you have to add or remove workers, or handle many executions at once. Running queue mode on SQLite isn't supported for that distributed setup. A monthly execution count for switching would be a heuristic to test. This page does not give one. Worker concurrency defaults to 10, and n8n recommends 5 or higher per worker. There is no workers-per-GB number.

Why did n8n run out of memory?

n8n does not restrict how much data each node can fetch and process. An execution runs out of memory when it needs more than the instance has. Documented drivers: amount of JSON data, size of binary data (kept in memory by default), number of nodes, Code or Function nodes, manual executions (n8n copies data for the frontend), and other workflows running at the same time. Before buying RAM: process smaller chunks (the docs' example is 200 rows instead of 10,000), avoid the Code node where you can, avoid manual runs on large data, split work into sub-workflows that return limited data, move binary data off memory, prune old executions, and cap production concurrency. For a JavaScript heap error, set NODE_OPTIONS=--max-old-space-size=SIZE.

Do managed plans and n8n Cloud need sizing?

Not from this dataset. Hostinger Managed n8n, n8n Cloud Starter (annual), n8n Cloud Pro (annual), Elestio Managed n8n (from), Render Hobby, and Railway Hobby have no verified RAM or vCPU here, so this guide does not assign them a size. The provider sizes those plans. Railway's plan is usage-based, not a fixed-spec VPS. n8n Cloud sizing is an execution-allowance question; this page does not quote allowances or a per-execution price. Once you know your size class, the renewal-first cost at a monthly execution count is the cost-by-executions guide, and the n8n Cloud vs self-hosted calculator takes that handoff. Executions per month to size stays a heuristic to test.