Choosing the Right VPS for n8n: A Practical Sizing and Setup Guide
Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.
Picking the right VPS for n8n directly determines whether your workflow automation stays fast and reliable or grinds to a halt under load. This guide walks through the resource requirements, provider considerations, and deployment patterns you need to run n8n reliably on your own infrastructure.
n8n is a workflow automation tool that competes with SaaS platforms like Zapier and Make, but its real advantage shows up when you self-host it: you control the data, you avoid per-execution pricing, and you can scale the underlying server to match your actual workload. That control only pays off, though, if the VPS you pick for n8n is sized and configured correctly. Undersize it and you’ll see stalled executions and webhook timeouts; oversize it and you’re paying for idle capacity every month. This article covers what actually matters when choosing a VPS for n8n, from CPU and memory baselines to database choices, reverse proxy setup, and ongoing maintenance.
Why Server Choice Matters for n8n
n8n is a Node.js application, and its resource profile depends heavily on how you use it. A handful of scheduled workflows that run once a day and send an email look nothing like a queue-mode deployment processing hundreds of webhook triggers per minute. Before you provision a VPS for n8n, it helps to separate the workload into three rough categories:
The database backend, the number of active workflows, and whether you’re running n8n in single-instance or queue mode with separate worker processes all shift the calculus. A VPS that’s fine for light usage will fall over quickly under heavy usage, particularly when Postgres and n8n are sharing the same small instance.
CPU and Memory Baselines
For a single-instance n8n deployment with SQLite or a small Postgres database, 1 vCPU and 2GB of RAM can technically run n8n, but this is a bare minimum, not a comfortable operating point. In practice, most self-hosters find that 2 vCPUs and 4GB of RAM is the realistic starting point for a VPS for n8n that also runs Postgres and a reverse proxy on the same box. If you plan to run resource-intensive Code nodes, process large JSON payloads, or add AI agent workflows that hold multiple concurrent HTTP connections open, budget for 4 vCPUs and 8GB of RAM or more.
Memory pressure is the most common failure mode. n8n keeps execution data in memory while a workflow runs, and if you’re also running Postgres, Redis (for queue mode), and Caddy or Nginx on the same host, memory contention shows up as slow executions long before you hit an out-of-memory kill.
Disk and I/O Considerations
Disk performance matters more than raw capacity for most n8n deployments. Workflow execution history, binary data (files passed between nodes), and Postgres’s write-ahead log all generate consistent disk I/O. An SSD-backed VPS is effectively mandatory — spinning disk or network-attached storage with high latency will produce noticeably slower workflow executions, especially ones that read or write files.
Storage capacity itself is usually not the bottleneck unless you’re storing large binary files (video, PDFs) inside n8n’s execution data instead of an external object store. A 40-80GB disk is generally sufficient for a moderate deployment, provided you’re pruning execution logs regularly.
Selecting a Provider for Your n8n VPS
Most mainstream cloud providers offer VPS instances suitable for n8n. What differentiates them for this use case is less about raw specs and more about network reliability, snapshot/backup tooling, and predictable pricing at the sizes n8n actually needs (small to medium instances, not enterprise-scale clusters).
Providers like DigitalOcean offer straightforward droplet sizing with predictable monthly billing, which suits a workload like n8n where you know roughly how much compute you need up front and don’t need to scale elastically minute to minute. Their managed database add-ons are also worth considering if you’d rather not operate Postgres yourself. For teams looking at higher-performance-per-dollar options, Hetzner is a common choice among self-hosters running n8n and similar automation stacks, offering competitive CPU and RAM allocations at their price points.
Whichever provider you choose, verify these before committing:
Regional Latency and Uptime
If your n8n workflows call external APIs that are region-sensitive (e.g., a SaaS product’s API hosted in a specific AWS region), place your VPS geographically close to that dependency. Round-trip latency adds up quickly in workflows with many sequential HTTP Request nodes. A workflow with fifteen API calls in series, each adding 150ms of avoidable latency because the VPS is on the wrong continent, turns a two-second execution into a much slower one.
Uptime matters less in the “five nines” enterprise sense and more in the practical sense of avoiding unplanned reboots. n8n recovers reasonably well from a restart (queued executions in database-backed queue mode aren’t lost), but frequent host instability will erode trust in time-sensitive automations like scheduled reports or webhook-triggered customer-facing flows.
Managed vs. Unmanaged VPS
A core decision when picking a VPS for n8n is whether to go managed or unmanaged. A managed VPS typically includes OS patching, monitoring, and sometimes a support team you can escalate to — useful if you don’t want to own Linux administration as an ongoing task. An unmanaged VPS is cheaper and gives you full root control, which is what most n8n self-hosters actually want, since you’ll be installing Docker, configuring a reverse proxy, and managing your own backup schedule regardless.
If you’re comfortable with basic Linux system administration — SSH key management, firewall rules, periodic apt upgrade — unmanaged is almost always the better value for a VPS for n8n. The n8n-specific configuration work (Docker Compose, environment variables, database tuning) is the same either way, so paying extra for OS-level management only makes sense if you genuinely don’t want to touch the underlying server at all.
Deploying n8n on Your VPS with Docker
Docker and Docker Compose are the standard way to run n8n on a VPS. The official n8n Docker image handles the application runtime, and pairing it with a Postgres container gives you a production-grade setup without manually installing Node.js or a database server on the host.
A minimal but realistic Docker Compose file for a VPS for n8n looks like this:
version: "3.8"
services:
postgres:
image: postgres:16
restart: unless-stopped
environment:
POSTGRES_USER: n8n
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DB: n8n
volumes:
- postgres_data:/var/lib/postgresql/data
n8n:
image: docker.n8n.io/n8nio/n8n
restart: unless-stopped
ports:
- "127.0.0.1:5678:5678"
environment:
DB_TYPE: postgresdb
DB_POSTGRESDB_HOST: postgres
DB_POSTGRESDB_DATABASE: n8n
DB_POSTGRESDB_USER: n8n
DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
N8N_HOST: n8n.yourdomain.com
N8N_PROTOCOL: https
WEBHOOK_URL: https://n8n.yourdomain.com/
volumes:
- n8n_data:/home/node/.n8n
depends_on:
- postgres
volumes:
postgres_data:
n8n_data:This pattern binds n8n’s port to localhost only, expecting a reverse proxy (Caddy or Nginx) to terminate TLS and forward traffic — a safer default than exposing port 5678 directly to the internet. For a deeper walkthrough of this exact setup, see the n8n self-hosted installation guide, and for the general Docker Compose fundamentals used above, Postgres in Docker Compose covers volume and environment variable patterns in more detail.
Database Setup: SQLite vs. PostgreSQL
n8n ships with SQLite as the default database, which is fine for evaluation or genuinely light single-user workloads. For anything running in production on a VPS for n8n with more than a trivial number of workflows, switch to Postgres. SQLite’s single-writer model becomes a bottleneck once you have concurrent executions, and Postgres also gives you standard backup tooling (pg_dump, WAL archiving) that SQLite doesn’t match as cleanly in a containerized environment.
If you’re already running Postgres for other services on the same VPS, you can share the instance with a separate database and user for n8n, rather than running two separate Postgres containers — this saves memory, which is usually the tighter constraint on a small VPS.
Reverse Proxy and TLS Termination
Every n8n VPS deployment intended for real use needs a reverse proxy in front of it for TLS termination and to keep the n8n container off a publicly exposed port. Caddy is a common choice because it handles automatic HTTPS certificate issuance and renewal with minimal configuration, but Nginx with Certbot works equally well if you’re already comfortable with that stack. Webhook-triggered workflows depend on a stable, correctly-configured WEBHOOK_URL matching your actual public domain — a mismatch here is one of the most common sources of “my webhook isn’t firing” issues in n8n deployments.
If you’re evaluating n8n against other automation platforms before committing to a self-hosted VPS approach, it’s worth reading a direct comparison like n8n vs Make to confirm self-hosting fits your actual requirements before investing time in server setup.
Scaling n8n: Queue Mode and Worker Processes
As workflow volume grows, a single n8n instance handling both the UI and every execution becomes a bottleneck. n8n supports a queue mode, backed by Redis, where a main instance accepts triggers and hands execution work off to separate worker processes. This lets you scale workers horizontally — running multiple worker containers, potentially across multiple VPS instances — while keeping a single main instance for the editor UI and webhook reception.
Queue mode is not necessary for light or moderate usage, but if you’re running a VPS for n8n that’s consistently hitting CPU limits during peak execution periods, it’s the correct next step before simply throwing more vCPUs at a single monolithic instance. Refer to the official n8n documentation for the specific environment variables required to enable queue mode and configure worker concurrency.
Monitoring Resource Usage Over Time
Once n8n is running, keep an eye on actual resource consumption rather than assuming your initial sizing estimate was correct. docker stats gives you a quick live view of container-level CPU and memory usage, and tools like Netdata or a simple cron-based disk/memory check script can alert you before you run out of headroom. Execution history in n8n’s database also grows continuously — configure EXECUTIONS_DATA_PRUNE and related environment variables so old execution data doesn’t silently consume your VPS’s disk over months of operation.
Security Considerations for a Self-Hosted n8n VPS
Because n8n often holds credentials for third-party services — API keys, OAuth tokens, database connection strings — the VPS running it is a meaningful security surface. Basic VPS hardening applies here just as it would to any production server: disable password-based SSH login in favor of keys, run a firewall (ufw or the provider’s security groups) restricting inbound traffic to only the ports you need, and keep the host OS and Docker images patched.
n8n-specific considerations include setting a strong N8N_ENCRYPTION_KEY (used to encrypt stored credentials at rest) and backing it up separately from the database — losing it makes stored credentials unrecoverable. If you expose the n8n editor UI to the internet at all, put basic authentication or your reverse proxy’s own access control in front of it in addition to n8n’s own user management, particularly if you’re on an older n8n version without built-in multi-user support enabled by default. Refer to the Docker security documentation for general container-hardening practices applicable to any Docker Compose stack, including this one.
Conclusion
A VPS for n8n doesn’t need to be large, but it does need to be sized deliberately around your actual workflow volume rather than a generic “small server” assumption. Start with 2 vCPUs and 4GB of RAM for a Postgres-backed single-instance deployment, move to queue mode with dedicated workers once you outgrow a single instance, and prioritize SSD-backed storage and a reasonable geographic location relative to the APIs your workflows depend on. Combine that with basic VPS security hardening and a reverse proxy handling TLS, and you have a self-hosted n8n setup that can run production workloads reliably without the recurring per-execution costs of a SaaS alternative.
Recommended: Ready to put this into practice? DigitalOcean is a tool we use for exactly this, and we have a real, disclosed affiliate relationship with them.
FAQ
How much RAM do I need for a VPS running n8n?
2GB is a workable minimum for light, single-instance usage with SQLite, but 4GB is a more realistic baseline once you add Postgres and expect moderate workflow volume. Heavier usage with AI agent workflows or queue mode benefits from 8GB or more.
Can I run n8n on a 1 vCPU VPS?
Yes, for light usage — a small number of workflows triggered infrequently. Once you have concurrent executions, webhook traffic, or Code nodes doing meaningful data processing, a single vCPU becomes a bottleneck and 2 or more vCPUs is recommended.
Do I need Postgres, or is SQLite good enough for n8n?
SQLite is fine for evaluation or very light personal use. Any production deployment on a VPS for n8n benefits from Postgres, since it handles concurrent writes better and gives you standard backup and restore tooling.
Is queue mode necessary for a self-hosted n8n VPS?
No — queue mode is only needed once a single instance can’t keep up with execution volume. Most moderate deployments run fine as a single instance with Postgres; queue mode with Redis and separate workers is a scaling step for higher-volume production workloads.
Leave a Reply