n8n Self-Hosted on a VPS: System Requirements and Production Setup in 2026

n8n is a popular workflow automation tool: connect APIs, databases, chat apps, and cron-like schedules without writing a full backend for every integration. Self-hosting gives you control over data residency, custom nodes, and cost at scale. This guide covers n8n system requirements in 2026, how to run n8n self-hosted on a VPS, and how to harden the deployment with a reverse proxy and TLS.

n8n System Requirements: What Actually Matters

Official and community guidance converges on sensible minimums for small teams:

• RAM: Treat 2 GB as a practical minimum for Docker or Node-based installs with light workflows. 4 GB is a better default if you run many concurrent executions, heavy HTTP payloads, or multiple workers.
• CPU: 2 vCPU is a comfortable baseline for production. Single vCPU can work for personal automations but spikes during workflow bursts may queue executions noticeably.
• Disk: SSD-backed storage. Workflow definitions and SQLite (if used) are small, but execution logs and binary data grow. Plan 20 GB+ unless you aggressively prune history.
• Network: Stable outbound HTTPS. Most integrations call external APIs. Unreliable NAT or aggressive sleep states on cheap laptops are why people move n8n self-hosted to a VPS.

These numbers align with typical n8n self-hosted VPS requirements: you are not mining crypto, but you are running Node.js, a database, and possibly queue workers. Undersizing RAM is the most common cause of OOM kills during peak automation hours.

Docker vs npm Install

Docker (recommended for most VPS setups)

Pros:

• Reproducible versions via pinned images.
• Simple upgrades by changing the image tag.
• Easy pairing with Docker Compose for Postgres, Redis, and n8n side by side.

Cons:

• You need basic Docker literacy (volumes, networks, compose).

npm / global Node install

Pros:

• Direct control without container layers.
• Can feel lighter on very small boxes if you know Node ops.

Cons:

• You own dependency drift, system Node upgrades, and process supervision.
• Harder to match production across machines.

For a self-hosted n8n deployment you intend to keep for months, Docker Compose on a VPS is usually the least fragile path.

Database Options: SQLite vs PostgreSQL

SQLite

• Best for: Single-instance n8n, personal automations, low concurrent write volume.
• Watchouts: Backups must be taken consistently; concurrent writes do not scale like a server database.

PostgreSQL

• Best for: Production n8n self-hosted setups, multiple users, higher execution volume, future scaling to queue mode.
• Watchouts: You must operate Postgres (updates, backups, connection limits).

If you outgrow SQLite, migrating to Postgres is a known path. Starting on Postgres avoids a later cutover when your automation stack becomes business-critical.

VPS Setup Step by Step

The following is a generic, distribution-agnostic outline you can adapt to Ubuntu, Debian, or similar:

1. Create a non-root sudo user and disable password SSH if you use keys.
2. Install Docker Engine and Docker Compose plugin (or docker-compose standalone).
3. Configure a firewall allowing SSH, HTTP, and HTTPS only.
4. Create directories for persistent data, for example /opt/n8n/data and /opt/n8n/postgres.
5. Write a compose file that pins the n8n image version and sets environment variables (encryption key, hostname, database URL).
6. Bring the stack up with docker compose up -d.
7. Verify the UI on localhost or over the LAN before exposing publicly.

Critical environment variables (names may vary slightly by version; check current n8n docs):

• A strong encryption key for credentials at rest.
• Webhook URL and public URL settings so triggers generate correct external links behind a proxy.
• Database connection string if using Postgres.

Never expose the n8n UI directly on port 5678 to the open internet without authentication layers and TLS. Treat it like an admin panel.

Reverse Proxy with Nginx

Put Nginx (or Caddy, Traefik) in front of n8n:

• Terminate TLS at the proxy.
• Enforce HTTP to HTTPS redirects.
• Optionally add basic auth or IP allowlists for extra safety (still use n8n’s own auth for users).

Typical pattern:

• Proxy / to http://127.0.0.1:5678 (or the container port).
• Set WebSocket and upgrade headers correctly. n8n uses websockets for the editor experience; misconfigured proxies cause flaky UI.

If you use Cloudflare, understand how websocket compatibility and caching interact with your hostname. Usually you want the orange-cloud proxy on, but caching disabled for the n8n path.

SSL Setup

Use Let’s Encrypt with certbot on the host, or a proxy that obtains certificates automatically.

Renewal: Automate with systemd timers or certbot’s cron hooks. Broken renewals are a common reason “automation stopped working” months after launch.

HSTS: After you confirm HTTPS works, consider HTTP Strict Transport Security headers at the proxy for browsers hitting any human-facing domains.

Performance Tuning

Practical knobs that help n8n self-hosted performance on a VPS:

• Concurrency limits: Cap parallel executions if you share the machine with other services.
• Prune execution data: Old runs consume disk and slow the UI.
• Separate Postgres resources: Give Postgres enough shared_buffers and connections for your load (small VPS: keep defaults modest).
• Queue mode (advanced): For heavy workloads, n8n supports queue-based execution with Redis and workers. That moves you from “single container” to a small distributed setup, still reasonable on a 4 GB to 8 GB VPS depending on volume.

Monitor CPU steal on budget hosts. If steal is high, workflow latency becomes unpredictable even when averages look fine.

Scaling Tips

• Vertical scale first: More RAM often fixes more problems than more workflows per minute on a starved box.
• Split concerns: Do not run a heavy Minecraft server on the same VPS as production n8n unless you measure headroom carefully.
• External webhooks: Ensure your provider timeouts match your longest-running nodes. Consider splitting long jobs into smaller workflows with queues or message buses.

Why Space-Node Fits n8n Self-Hosting

Space-Node focuses on EU-friendly hosting with predictable resources for always-on services. n8n self-hosted workloads benefit from:

• Low-latency routes to European SaaS APIs many teams use.
• VPS plans that map cleanly to the 2 GB to 4 GB RAM sweet spot for automation.
• A mental model where your automation engine is as reliable as your production apps.

If you already host game servers or Discord bots with Space-Node, colocating n8n on a separate small VPS isolates blast radius: a runaway workflow does not take down your player-facing services.

Backups and Disaster Recovery

Workflow JSON and credentials are valuable. Treat them like application data:

• Database dumps on a schedule if you use Postgres (pg_dump with rotation).
• Volume snapshots at the hypervisor level if your provider offers them, in addition to logical backups.
• Off-site copies so a single machine loss does not erase automation definitions.

Test a restore once. Untested backups are wishes.

Updates and Change Management

Pin image tags in Compose, then upgrade deliberately:

• Read n8n release notes for breaking changes in nodes or environment variables.
• Upgrade in a maintenance window if you run business-critical hooks.
• Keep a staging Compose stack on a tiny VPS or local machine to validate workflows before touching production.

Troubleshooting Common Failures

Webhooks suddenly 404 in SaaS tools: Your public URL or TLS cert changed. Re-check WEBHOOK_URL style settings and reverse proxy paths.

Out of memory during large file transfers: Raise RAM or stream data instead of loading huge payloads into memory in Function nodes.

Database connection exhaustion: Lower pool sizes or add connection limits on Postgres. Bursty parallel workflows can open many connections at once.

FAQ

Is 2 GB RAM enough for n8n self-hosted?

Yes, for light use with Docker and careful concurrency. For multiple active users, Postgres, and busy schedules, 4 GB is a safer production default.

Should I use SQLite or PostgreSQL on a VPS?

SQLite is fine for solo or low-traffic setups. Choose PostgreSQL when you care about durability under concurrent use or plan to grow into queue mode.

Can I run n8n without a domain name?

You can on a private network, but webhooks from external SaaS products need a public HTTPS URL. A domain with valid TLS is the standard approach.

How do I secure a self-hosted n8n instance?

Use TLS, keep n8n updated, restrict admin exposure (VPN, firewall, or SSO where supported), rotate credentials, and back up encryption keys and databases.

Docker Compose or Kubernetes for n8n?

Docker Compose on a single VPS matches most small teams. Kubernetes adds value when you already operate clusters and need multi-node resilience.

---

Requirements and UI details change with n8n releases. Verify version-specific docs before upgrading production.