Sizing n8n Infrastructure: RAM, CPU, and Storage Requirements

Calculating hardware requirements for self hosted n8n prevents unexpected workflow crashes, execution timeouts, and out-of-memory errors before you deploy to production. Many developers start running workflows on a shared 1 GB VPS without realizing how the Node.js runtime and PostgreSQL backend consume resources under concurrent loads. When an HTTP Request node ingests a 10,000-row payload or multiple webhooks fire at the exact same second, that modest server quickly runs out of headroom.

Getting your infrastructure sizing right demands an understanding of how n8n uses compute, memory, and storage during workflow execution. If you size your instance incorrectly, workflows fail silently or the whole Docker daemon freezes. Let's break down the actual compute benchmarks, memory footprints, and disk growth patterns you must plan for when hosting your own workflows, along with when it makes sense to evaluate n8nautomation.cloud for dedicated, worry-free deployment.

Minimum Hardware Specifications for Self Hosted n8n

Your hardware floor depends on execution patterns rather than the raw number of inactive workflows sitting on your canvas. An idle workflow with 50 nodes uses virtually zero CPU. Conversely, a five-node workflow parsing nested JSON files every two minutes can overwhelm a single-core machine. Running a self hosted n8n instance reliably requires allocating resources according to three clear tiers:

• Development and Lightweight Testing: 1 vCPU, 2 GB RAM, and 20 GB SSD storage. This tier handles simple cron triggers, low-frequency webhooks, and straightforward API notifications where payloads remain below 500 KB.
• Standard Business Automation: 2 vCPUs, 4 GB RAM, and 50 GB NVMe SSD storage. This configuration comfortably supports 20 to 50 active workflows, concurrent webhook triggers from CRMs, basic database syncs, and modest data transformation pipelines.
• High-Throughput Production & ETL: 4 vCPUs, 8 GB to 16 GB RAM, and 100+ GB high-IOPS storage. This sizing is essential if you process large CSV files, handle binary file manipulation (such as image resizing or PDF generation), or orchestrate complex AI workflows using LangChain and local vector memory.

Do not attempt to run n8n in production on a 1 GB machine without swap space enabled. Node.js itself typically claims around 150 MB to 250 MB of memory just to boot the application core and register community nodes. The moment an incoming webhook triggers a workflow execution, memory usage jumps. Without at least 2 GB of addressable memory, the Linux kernel OOM (Out Of Memory) killer will terminate your process without warning.

Memory Allocation and Node.js Garbage Collection Bottlenecks

Node.js runs single-threaded on top of the V8 JavaScript engine. By default, V8 enforces a conservative memory heap limit (around 1.4 GB on 64-bit systems unless explicitly overridden). When you build data-heavy automation in n8n, this heap limit becomes your primary operational bottleneck.

Consider how data moves between nodes. Every item emitted by a node exists as an individual JSON object inside server memory. If your HTTP Request node fetches a 10 MB JSON payload containing thousands of user records, n8n parses that raw string into structured JavaScript objects. Inside the V8 heap, structural object overhead multiplies that 10 MB payload into 40 MB to 60 MB of live memory references. If you pass that data through a Code node that creates a mapped clone of the array, memory consumption doubles again in an instant.

To mitigate this risk, you must configure the Node.js max heap size explicitly inside your container environment using the NODE_OPTIONS parameter:

NODE_OPTIONS="--max-old-space-size=3584"

On a 4 GB machine, setting --max-old-space-size=3584 leaves roughly 500 MB of system RAM for the operating system, Docker daemon, and reverse proxy (such as Caddy, Traefik, or Nginx). Never set this value to match your total system RAM. Starving the host OS of memory causes SSH daemon drops and catastrophic host lockups.

Database I/O and Disk Growth from Execution History

Storage capacity is rarely the problem when you first launch a self-hosted instance. Storage write endurance and unmanaged database bloat are what cause servers to fail after four to six months of operation.

By default, n8n writes the full input and output payload of every single executed node into its database. While this makes debugging past runs remarkably convenient, it generates massive table growth. If a workflow runs once every minute and logs 50 KB of payload context across its steps, it writes approximately 72 MB of execution data per day. Over a year, that single background check accumulates over 26 GB of database rows.

If you rely on SQLite for persistent storage, concurrent writes from incoming webhooks will frequently trigger database is locked errors. For any serious workload, you must run PostgreSQL alongside n8n. However, PostgreSQL requires dedicated disk write throughput (IOPS) and explicit pruning rules configured in your environment variables:

• EXECUTIONS_DATA_PRUNE=true: Enables the automatic background pruning process.
• EXECUTIONS_DATA_MAX_AGE=168: Prunes execution records older than 168 hours (7 days). Set this lower (24 to 48 hours) for high-volume instances.
• EXECUTIONS_DATA_SAVE_ON_ERROR=all: Ensures failed workflow data is saved for troubleshooting while successful routine runs can be omitted or pruned aggressively.
• EXECUTIONS_DATA_SAVE_ON_SUCCESS=none: Skips recording node execution payloads for successful runs, dramatically reducing disk write cycles on high-frequency webhooks.

Even with pruning enabled, PostgreSQL does not automatically return freed disk space to the host operating system. It marks space as reusable internally. Without periodic VACUUM operations or scheduled table maintenance, your disk footprint will continue expanding until the filesystem hits 100% capacity.

How to Install n8n with Proper Resource Limits via Docker Compose

When learning how to install n8n for production use, container resource limits are just as critical as the application environment flags. Docker containers without limits can consume every spare CPU cycle and byte of host RAM, pulling down your entire VPS infrastructure.

Follow these steps to deploy n8n with explicit resource boundaries and PostgreSQL integration:

1. Create a dedicated directory on your server and navigate into it:

   mkdir -p /opt/n8n-production && cd /opt/n8n-production

2. Create a robust docker-compose.yml file containing CPU limits, memory reservations, and pruning variables:

   version: '3.8'
   services:
     postgres:
       image: postgres:16-alpine
       restart: always
       environment:
         - POSTGRES_USER=n8n_db_user
         - POSTGRES_PASSWORD=YourSecureDatabasePassword
         - POSTGRES_DB=n8n_production
       volumes:
         - ./postgres_data:/var/lib/postgresql/data
       deploy:
         resources:
           limits:
             cpus: '1.5'
             memory: 2048M
   
     n8n:
       image: docker.n8n.io/n8nio/n8n:latest
       restart: always
       ports:
         - "5678:5678"
       environment:
         - DB_TYPE=postgresdb
         - DB_POSTGRESDB_HOST=postgres
         - DB_POSTGRESDB_PORT=5432
         - DB_POSTGRESDB_DATABASE=n8n_production
         - DB_POSTGRESDB_USER=n8n_db_user
         - DB_POSTGRESDB_PASSWORD=YourSecureDatabasePassword
         - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
         - EXECUTIONS_DATA_PRUNE=true
         - EXECUTIONS_DATA_MAX_AGE=72
         - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
         - NODE_OPTIONS=--max-old-space-size=2560
       volumes:
         - ./n8n_data:/home/node/.n8n
       deploy:
         resources:
           limits:
             cpus: '2.0'
             memory: 3072M
           reservations:
             memory: 1024M
       depends_on:
         - postgres

3. Set the proper folder permissions so the unprivileged n8n container user (UID 1000) can write execution logs and cache community nodes without permission denied errors:

   chown -R 1000:1000 ./n8n_data

4. Spin up the containers in detached mode:

   docker compose up -d

When to Scale Compute vs Moving to Managed n8n Hosting

Once you implement these configurations, maintaining a self-hosted instance shifts from initial deployment to ongoing systems administration. You must manage security updates, rotate database credentials, patch Linux vulnerabilities, manage reverse proxy SSL certificates, and monitor disk bloat. Over time, that overhead distracts your technical team from actually building automation logic.

For individuals and growing development teams, evaluating low cost n8n hosting becomes a practical operational calculation. When you self-host on a cloud VPS provider:

• You pay $10 to $25 per month for a decent 2 vCPU, 4 GB RAM compute instance with NVMe disks.
• You spend two to four hours each month running OS updates, checking storage utilization, and resolving broken Docker volume permissions.
• You remain solely responsible if a memory spike takes down your instance while you are away from your workstation.

This is where finding the best n8n hosting setup makes financial and technical sense. Instead of managing operating system dependencies, firewall rules, and container resource limits yourself, using a dedicated service like n8nautomation.cloud gives you an enterprise-grade runtime starting at just $4 per month. You get your own dedicated instance with a custom subdomain (yourname.n8nautomation.cloud), automatic backups, and guaranteed 24/7 uptime without touching a single server configuration file.

Unlike generic PaaS providers where n8n runs inside a shared container that sleeps after inactivity, dedicated n8n managed hosting keeps your webhooks alive around the clock. Because it runs the full open-source Community Edition, you retain complete access to all 400+ native integrations, community nodes, and advanced logic capabilities.

Migrating Existing Workflows to Dedicated Infrastructure

If you already have a self-hosted instance that is running out of disk space or crashing due to memory exhaustion, migrating does not require tedious manual recreation. Exporting dozens of workflows manually via JSON files often breaks webhook URLs and leaves credentials scattered in unorganized files.

Platform transitions can be handled in seconds using the native migration tool provided by n8nautomation.cloud. The migration utility connects directly to your old n8n instance and your new instance using the n8n REST API:

1. Generate an API key on your existing self-hosted n8n instance under Settings > n8n API.
2. Provision your dedicated instance on n8nautomation.cloud and generate an API key in your new environment.
3. Input both instance URLs and API keys into the migration dashboard. The migration utility transfers all workflow structures, node configurations, and complex routing logic within seconds.
4. Reconnect your credentials inside the new instance. For security integrity, credentials are never migrated over the wire, ensuring your third-party API tokens remain protected.

Advanced users also gain direct access to instance logs right inside the management dashboard. If a custom Code node throws an uncaught exception or an external webhook provider returns an unexpected response, you can inspect the raw container stdout logs immediately without needing an SSH terminal open.

You can also change your instance domain at any time—switching between your free subdomain or attaching a custom domain to match your company branding. Sizing your infrastructure correctly means knowing your limits. Whether you choose to tune your own Docker configurations or leverage a managed platform, understanding compute, RAM, and disk usage ensures your automation pipeline never drops a single mission-critical event.