n8n’s documented minimum is 2 vCPU, 2 GB RAM, and 20 GB disk — but that is a development figure. For production n8n on a Hostinger VPS, the realistic floor is KVM 2 (2 vCPU / 8 GB RAM) with Docker and PostgreSQL, and KVM 1 is fine only for light personal use.
The short answer: size by workload, not by the minimum
| Your workload | RAM / vCPU | Hostinger plan | Database |
|---|---|---|---|
| Testing, a few personal workflows | 2–4 GB / 1–2 vCPU | KVM 1 — | SQLite is fine |
| Production: scheduled + webhook flows | 4–8 GB / 2 vCPU | n8n VPS (KVM 2) —
63% OFF Verified Oct 8, 2026
VPS KVM 2 (n8n template)
$8.99/mo
24-month plan, paid upfront Renews at $14.99/mo
| PostgreSQL |
| Heavy: parallel executions, AI nodes, big payloads | 8–16 GB / 4 vCPU | KVM 4 —
70% OFF Verified Oct 8, 2026
VPS KVM 4
$12.99/mo
24-month plan, paid upfront Renews at $28.99/mo
| PostgreSQL (+ queue mode) |
Prices render from our deals database (checked October 9, 2026); renewal rates are shown in the deal cards.
The line most sizing guides will not give you: 4 GB RAM and 2 vCPUs is where production n8n actually starts working. The 2 GB minimum keeps the process alive, but the moment PostgreSQL runs alongside n8n and a workflow handles a chunky JSON payload, 2 GB starts swapping and executions slow to a crawl. Budget for headroom and you stop fighting your own server.
KVM 1 vs KVM 2 for n8n
KVM 1 (1 vCPU / 4 GB RAM / 50 GB NVMe) is the budget pick: 4 GB of RAM is generous for the money, and it runs n8n with SQLite happily for personal automations — a dozen workflows on schedules, some webhooks, nothing mission-critical. Its limits show up under concurrency: one vCPU means parallel executions queue, and adding PostgreSQL on the same box eats a meaningful share of that 4 GB.
The n8n VPS (KVM 2) (2 vCPU / 8 GB RAM / 100 GB NVMe) is the production pick and the plan Hostinger’s own one-click n8n template is sized around: 8 GB comfortably fits n8n + PostgreSQL + headroom for parallel executions and AI nodes, and the second vCPU keeps the UI snappy while workflows run. If n8n runs anything your business depends on, this is the plan.
Renewal honesty: both plans renew at roughly 1.8x the intro price after the first term (exact rates in the deal cards). Size for what you will need at renewal price, not just the cheap first term.
Docker vs npm: how to run n8n
Docker is the recommended way to run n8n — upgrades are a single image pull (docker compose pull && docker compose up -d), the whole stack lives in one compose file, and the environment is identical everywhere. Hostinger’s n8n VPS template uses Docker under the hood, which is another reason to start there.
npm (bare Node.js) works and uses slightly less RAM (no container overhead), but you own the Node version management, process supervision (pm2/systemd), and upgrade procedure. It made sense in 2021; in 2026 Docker is the default for a reason. Only choose npm if you have a specific constraint, like a minimal 1 GB box where every megabyte counts.
Either way, run n8n on Linux (Ubuntu 24.04 LTS) — n8n’s own docs and the community treat Linux + Docker as the production path.
SQLite vs PostgreSQL
n8n ships with SQLite by default: zero setup, perfectly fine for testing and personal use. Switch to PostgreSQL when any of these are true:
- You run webhooks under real traffic — SQLite locks on concurrent writes; Postgres does not.
- You exceed a few thousand executions per month and the database keeps growing.
- You want queue mode (Redis + worker processes for parallel execution) — it requires Postgres.
- Multiple team members use the same instance.
PostgreSQL 16 is the current sweet spot for new installs. On KVM 2, running Postgres in its own Docker container next to n8n is the standard production layout and leaves RAM to spare.
Disk, backups, and the things people forget
- Disk: 50 GB (KVM 1) covers the OS, Docker, and a large execution history; 100 GB (KVM 2) is comfortable for production. Execution history accumulates — set n8n’s data-pruning environment variables so the database does not grow forever.
- Encryption key: back up your
N8N_ENCRYPTION_KEYseparately. Lose it and every stored API credential becomes permanently unreadable, even with a database backup. - Backups: Hostinger includes free weekly automatic VPS backups; take a manual snapshot in hPanel before upgrades. For the database itself, a nightly
pg_dumppushed offsite is the professional standard. - Webhooks: set the
WEBHOOK_URLenvironment variable to your public HTTPS domain, or n8n generates useless localhost URLs in webhook nodes. - Monitoring: run
docker stats n8nthrough a normal day before committing to a plan — if memory pins near the ceiling during executions, move up a tier before production.
Three real-world sizing scenarios
Scenario 1 — personal automation (KVM 1): 15 workflows, mostly scheduled (sync Notion to calendar, scrape prices daily, Telegram alerts), SQLite, a few webhooks a day. Memory sits around 1.5–2 GB. KVM 1 handles this with room to spare — this is the setup the entry plan was made for.
Scenario 2 — small business (n8n VPS / KVM 2): 60 workflows, order webhooks from Shopify, AI summarization nodes, Postgres database, two team members in the editor. Memory 3.5–5 GB under load; the second vCPU keeps executions from blocking the UI. This is the production sweet spot and the plan we recommend for anything business-critical.
Scenario 3 — agency / heavy (KVM 4): hundreds of workflows across client sub-accounts, queue mode with workers, large file payloads, Postgres + Redis. Memory 8–12 GB. KVM 4’s 16 GB gives the headroom queue mode needs — workers multiply RAM usage, so size generously here.
The pattern: start one tier above what the minimums suggest, watch docker stats for a week, and scale only when the numbers say so. Upgrading a Hostinger VPS plan from hPanel does not require reinstalling, so there is no penalty for starting lean.
FAQ
What are the minimum requirements to run n8n on a VPS?
The documented minimum is 2 vCPU, 2 GB RAM, and 20 GB disk — but that covers development and testing only. For production, plan on 4–8 GB RAM, 2+ vCPU, 50+ GB NVMe, and PostgreSQL.
Is KVM 1 enough for n8n?
For personal use — a handful of scheduled workflows with SQLite — yes, KVM 1’s 4 GB RAM is fine. For production, webhooks, or PostgreSQL on the same box, step up to the n8n VPS (KVM 2).
Should I run n8n with Docker or npm?
Docker. Upgrades are one command, the stack is reproducible, and Hostinger’s n8n template uses Docker. Choose npm only for severely RAM-constrained boxes where container overhead matters.
When should I switch from SQLite to PostgreSQL?
When you have real webhook traffic, thousands of monthly executions, multiple users, or want queue mode. SQLite locks on concurrent writes; PostgreSQL handles them cleanly.
How much disk space does n8n need?
n8n itself is small — the growth is execution history and logs. 50 GB is plenty to start; enable n8n’s pruning settings and keep a nightly database backup offsite.
Can I upgrade my VPS later if n8n outgrows it?
Yes — Hostinger lets you scale a VPS to a larger KVM plan from hPanel without reinstalling. Start at KVM 2 for production; scale to KVM 4 when parallel executions or AI workloads demand it.
Next steps: compare flat VPS pricing with usage billing in Hostinger vs Railway for n8n, or see all five hosts ranked in our best VPS for n8n guide.
Queue mode deep dive: when and how to enable it
The page mentions queue mode briefly. Here is the full picture. Standard n8n executes workflows in the main process: each execution consumes memory in the same Node.js process, and concurrent executions compete for the same event loop. Queue mode separates execution into worker processes coordinated by Redis, allowing true parallelism.
When queue mode becomes necessary:
- You regularly have 5+ workflows executing simultaneously and see executions queuing or timing out.
- Individual workflow executions take minutes (large data processing, AI chains with multiple model calls) and block other executions.
- You need execution isolation: one workflow crashing should not affect others.
- You want to scale horizontally by adding more worker processes (or eventually more servers).
What queue mode requires: PostgreSQL (mandatory, SQLite is not supported), Redis (for the job queue), and additional RAM. Each worker is a separate Node.js process consuming 200-500 MB. On KVM 2 with 8 GB, you can comfortably run 2-4 workers alongside the main process, Postgres, and Redis. On KVM 4 with 16 GB, 6-10 workers are realistic.
The honest cost: queue mode adds operational complexity (three services to monitor instead of one) and RAM overhead. Do not enable it preemptively. Run in standard mode until you have evidence of execution queuing, then migrate. The migration itself requires a maintenance window: export workflows, reconfigure, import, test.
n8n performance tuning: environment variables that matter
Beyond plan sizing, these configuration settings significantly affect n8n performance on a VPS:
| Variable | What it controls | Recommendation |
|---|---|---|
| EXECUTIONS_DATA_PRUNE | Whether old execution data is deleted | true; set MAX_AGE to 168 hours (7 days) for production |
| EXECUTIONS_DATA_MAX_AGE | How long execution data is kept | 168 for production; 24 for high-volume instances |
| DB_POSTGRESDB_POOL_SIZE | Database connection pool | Increase to 20-30 on KVM 2+ for concurrent workloads |
| N8N_DEFAULT_BINARY_DATA_MODE | How binary data (files) is stored | filesystem (not memory) for any workflow handling files |
| WEBHOOK_URL | Public URL for webhook nodes | Must be set correctly or webhooks generate broken URLs |
| N8N_ENCRYPTION_KEY | Encrypts stored credentials | Set explicitly; back up separately; never lose this |
| GENERIC_TIMEZONE | Timezone for scheduled workflows | Set to your timezone; default UTC causes schedule confusion |
The binary data mode setting deserves special attention. By default, n8n may hold binary data (downloaded files, images, PDFs) in memory during workflow execution. A workflow processing a 500 MB file with binary data in memory mode will crash on any plan. Set filesystem mode and n8n writes binary data to disk instead, using dramatically less RAM.
Monitoring and alerting: knowing before your users do
Production n8n needs monitoring beyond docker stats. Build this stack:
- Uptime monitoring: an external service (UptimeRobot, Better Stack) hitting n8n's health endpoint every minute. If n8n stops responding, you get alerted before workflow failures cascade.
- Execution failure alerts: configure an n8n error workflow (a workflow triggered on execution failure) that notifies you via Telegram, email, or Slack. Without this, failed executions sit silently in the execution log.
- Disk space alerts: a simple cron job checking df -h output and alerting when disk exceeds 80%. Execution history and Docker logs fill disks gradually, then suddenly.
- Memory trend tracking: log docker stats output to a file daily, or use a lightweight monitoring agent. You want to see the trend: is memory usage creeping up week over week? That signals a leak or growing workload that needs attention before it becomes an outage.
- Workflow-specific monitoring: for business-critical workflows, add a final node that logs successful completion to an external system. Absence of the success log within the expected window triggers investigation. This catches the workflow did not run at all failure mode that execution monitoring misses.
Disaster recovery: backup and restore procedures
The page mentions backups briefly. Here is the complete disaster recovery plan:
- What to back up: the PostgreSQL database (contains workflows, credentials metadata, execution history), the n8n encryption key (without this, credentials are unrecoverable), the Docker Compose file and environment configuration, and any custom nodes or files in the n8n data directory.
- Backup method: nightly pg_dump of the n8n database, compressed and pushed to off-server storage (S3, Backblaze B2, or even a second VPS). The encryption key goes to a password manager, not the same backup destination. Rotate backups: keep 7 daily, 4 weekly, 3 monthly.
- Hostinger snapshots as a layer: enable Hostinger's VPS snapshots for full-disk recovery. Snapshots complement database backups: snapshots restore the entire server state quickly, database dumps allow granular recovery (restoring a single accidentally deleted workflow).
- Restore procedure: document the exact steps: provision a fresh VPS (same or larger plan), install Docker, restore the database dump, place the encryption key and config files, start containers, verify workflows load and credentials decrypt correctly. Write this document now, not during an outage.
- Test annually: perform a full restore to a temporary VPS once a year. Verify that workflows execute, webhooks respond, and credentials work. Delete the temporary VPS afterward. This test is the only proof your backups actually work.
For the AI automation alternative that eliminates server management entirely, see our managed n8n hosting guide.