n8n server requirements: check your workload before choosing a VPS

Choose an n8n server by the setup you will run and the busiest work it must handle. A server that opens the workflow editor may still struggle when several workflows process files at once. If you already have a server, check its available resources and permissions before ordering another one.

This guide is for someone planning a small business automation who can describe its inputs, outputs and schedule. You will finish with a checklist for your existing host or a new server quote. Installing n8n comes after that decision; no terminal knowledge is needed here.

Which minimum applies to your setup?

As checked on 24 September 2026, n8n’s Docker Compose guide specifies at least 4 GB RAM and 2 vCPUs for the setup it describes. That setup includes the sandbox services used by n8n Assistant to run generated code. The guide explains that the sandbox needs additional resources.

Those figures are a prerequisite for that particular stack, not a promise that every workflow fits. They also should not be presented as the universal minimum for every n8n installation. Check the installation options for the components you actually intend to run.

RAM is working memory used while data is being processed. A vCPU is a virtual processor allocated to the server. Both must also cover the operating system and any other applications sharing the machine. If your plan includes 4 GB RAM, that does not mean all 4 GB is available to n8n.

Describe the busiest run, not just the monthly total

A workflow is your sequence of automation steps; an execution is one run. Concurrency means how many executions run at the same time. Thirty executions spread across a month tell you little about the resources needed for thirty overlapping executions.

Write down the following for your own task. If a value is unknown, make it something to check before committing to a long hosting term.

Inputs for a useful server decision
Question	What to record	Why it matters
What passes through one run?	Typical and largest expected record batches; attachment types and sizes.	A small text response and a folder of documents have different memory and storage needs.
What can overlap?	Schedules that coincide, incoming bursts, and retries while other runs are still active.	The peak can be much higher than the daily average.
Where does the work happen?	External app requests versus code, file conversion or other processing on your server.	Waiting for another service and doing computation locally put different demands on the machine.
What will you retain?	Required execution history, saved files and recovery copies.	Disk use continues to grow after a workflow finishes unless retention is controlled.
When must the result arrive?	Your acceptable delay and what happens if a run fails.	A task that may finish later has different requirements from one holding up a customer response.

For example, a daily text summary and a document-processing workflow triggered by an inbox may each be called “one workflow.” The second can receive several large inputs together. This is an illustration of what to describe, not a capacity estimate for either task.

n8n’s memory guidance identifies data size, workflow nodes and overlapping runs as memory factors. Manual runs in the editor also use extra memory to show the data. A successful small manual example is therefore useful for checking logic, but it does not establish the resources required for the real schedule and inputs.

Can your existing host support it?

Ask these questions using the exact hosting plan you already have. A “Node.js supported” badge alone does not answer them.

Can this plan run the chosen n8n setup continuously? Confirm support for its required container services and permissions, whether applications sleep, and who restarts them after failure or a server reboot. A machine that is off when work arrives cannot process it then.
What resources can n8n actually use? Record RAM, CPU and disk limits for the application, not just the whole server. Ask about other applications sharing that allowance and whether usage graphs and error logs are available.
Where does permanent data live? Confirm that the database and required files survive container replacement and updates. A persistent volume is storage kept separately from a container’s disposable files; persistence alone is not a backup.
Can it make the connections your workflow requires? Identify outgoing app connections and any incoming webhooks—requests another service sends to start a workflow. Public access needs an appropriate HTTPS and access-control setup; n8n’s TLS guidance covers encrypted connections. An outgoing-only task does not by itself require exposing the editor publicly.
Who maintains and recovers it? Name the person responsible for server and n8n updates, backup checks and failed runs. More RAM does not replace that responsibility.

If support cannot confirm a required capability, treat it as unresolved. Extra disk space will not fix a plan that cannot run the required services. If the capabilities are present, the next step is a representative workload check, not an automatic purchase.

Include the database and retained files

n8n uses SQLite by default and also supports PostgreSQL. SQLite keeps the database in a local file; PostgreSQL runs as a database service. Record which your chosen deployment uses, where it runs and whose resource allowance it consumes. A separately billed managed database is not an automatic requirement for every small instance.

Saved execution history can fill the disk. Decide how much history you need for investigating failures, then use n8n’s execution-data controls to retain useful records and remove old ones. Include attachments too: n8n’s binary-data guidance explains that file data is held in memory by default and that storage choices affect large-file handling.

Confirm backup coverage for the database, credential encryption key and any separately stored files. The recovery guide explains why exported workflows alone are not a full backup. Keeping an existing suitable backup arrangement is a valid choice.

You may see queue mode in larger deployment guides. It separates receiving work from executing it, using worker processes and Redis to coordinate pending jobs. It adds components to operate; it is not a box every small server must tick. If you need that architecture, use the queue-mode requirements and budget for the whole system. The distributed setup does not support SQLite.

Check the workload before committing

Once your maintainer has installed the intended setup, use a test version of the workflow with representative inputs. Route writes and messages to test destinations so a capacity check does not create duplicate customer records or send real notifications.

Agree on a simple acceptance check:

Run the usual input and the largest input you reasonably expect, including the expected busiest overlap.
In the hosting dashboard, inspect application or container memory, CPU and disk use during those runs. Your maintainer should supply these measurements if the dashboard does not expose them.
Confirm the output is correct and arrives within the delay you recorded. Check execution errors and server logs for memory failures or restarts.
Check disk growth over repeated runs and verify that the planned retention policy operates. Confirm the recovery arrangement separately before relying on the workflow.

Leave capacity for other services, maintenance and expected growth; a run that only just fits is a poor basis for committing. The useful evidence is the measured peak for your inputs and configuration, not a generic “workflows per server” number. n8n’s performance documentation likewise ties results to the workflow and deployment.

If memory is the constraint, reducing the batch size or the data carried between steps may help before buying more RAM. If executions are slow while local resources remain available, investigate the connected service and its limits before assuming another vCPU will solve it.

Choose your next step

Existing hosting meets the capability checks: arrange the representative check there first. Keep it if the workflow fits with room for the other work on that server.

A required capability or measured resource is missing: take your workload notes to a candidate host. Ask for a configuration that supports the selected deployment, persistent storage and the observed peak, plus the resize procedure and any downtime. A quote is the next decision input; it is not proof of capacity.

Nobody can maintain the server: consider n8n Cloud, then check its features and resource limits against the same task. You still own the workflow’s inputs and results. Our n8n cost guide covers the separate budget decision.

Before buying, your notes should name the deployment components, peak workload, storage and retention, maintenance owner, and next verification step. An unknown item is a question to resolve, not a reason to choose a larger plan at random.

Sources and useful links

Docker Compose setup requirements — check the resources and components of the Assistant sandbox stack before applying its minimum elsewhere.
Memory-related errors — identify workload factors and ways to reduce memory demand.
Database choices — distinguish the default SQLite database from a PostgreSQL deployment and check current compatibility.
Execution-data retention — plan disk use and removal of old records.
Back up and restore — check whether your recovery copies include the data and key your instance needs.
Performance and benchmarking — understand why a published example cannot establish your workflow’s capacity.