n8n VPS Hosting on KVM and NVMe

n8n is a long-running Node.js application. It has to stay up between requests so its schedule triggers fire on time, it needs a stable public HTTPS address so services like Stripe, GitHub or Typeform can deliver webhooks to it, and the standard way to run it is Docker with a database alongside. Shared hosting is built around the opposite model: short PHP requests, no root, no Docker, and background processes that get killed when they run too long or use too much memory.

n8n's memory use is also bursty. An instance can sit idle for an hour and then pull thousands of rows into memory in one execution, especially with a Code node or binary files. On a VPS that burst lands on RAM you control. On shared hosting it lands on a process limit you don't.

The other reason is cost shape. n8n Cloud bills by workflow executions; a VPS bills by the month. A single workflow on a five-minute schedule is about 8,640 executions in a 30-day month before you build anything else. On a VPS that number does not change the bill. Our n8n self-hosting tutorial walks through the arithmetic.

The number of workflows matters less than three things: how many executions run at the same time, how big the data each one carries is, and whether you use the Code node, binary files or a headless browser. n8n's own documentation names JSON volume, binary data size, node count and the Code node as the drivers of memory use, and manual runs from the editor cost extra because the data is copied for the UI. For reference, n8n's Docker Compose guide asks for at least 2 vCPUs and 4 GB of RAM.

Disk is the other thing that grows. n8n saves execution data by default, so a busy instance adds Postgres rows every day. Set EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE_MAX_COUNT, and consider EXECUTIONS_DATA_SAVE_ON_SUCCESS=none if you only need failed runs. You can upgrade a Devoster VPS to a larger plan from the panel later, so start where the table puts you rather than two sizes up.

Out of the box n8n stores everything in a SQLite file inside its data directory. That is fine for a test instance. For anything you depend on, use PostgreSQL from day one, for three reasons:

• Switching later is not an in-place migration. Moving an existing instance from SQLite to Postgres means exporting and re-importing workflows and credentials, not flipping a setting.
• Queue mode needs Postgres. n8n does not support queue mode on SQLite, so the database choice decides whether you can scale out on the same server later.
• Execution history is write-heavy. A busy instance writes a row for every run. Postgres on NVMe handles that steady stream of small writes well, and its default memory settings are modest enough to share a 4 GB server with n8n.

Whichever you choose, keep persisting the n8n data volume. It holds the encryption key that protects every stored credential, and a database restored without that key gives you workflows with unreadable credentials.

In the default mode, one n8n process receives webhooks, serves the editor and runs every execution. Queue mode (EXECUTIONS_MODE=queue) splits that: the main process accepts triggers and puts executions on a Redis queue, and separate worker processes pick them up.

It is worth the extra moving parts when long executions hold up others, when bursts of webhooks arrive faster than one process clears them, or when one heavy workflow should not be able to stall the editor. It is not worth it for an instance that runs a few dozen workflows on schedules; scale up the plan first.

Two things to plan for. Queue mode multiplies memory, not just CPU, because every worker is a full Node.js process, and you add Redis. That is why the Advanced plan (4 vCPU / 8 GB) is where running main, Redis and one or two workers on one server starts to make sense. And every worker needs the identical N8N_ENCRYPTION_KEY as the main process, or workers cannot decrypt credentials.

Devoster VPS plans are unmanaged: we provide the KVM server, the network and the backups, and you install and run n8n. The full walkthrough, with the Compose file and every environment variable explained, is in How to self-host n8n on a VPS. The short version:

• Deploy Ubuntu 24.04 or Debian 12 and harden it first: SSH keys, a firewall that allows only 80, 443 and SSH, automatic security updates. Our VPS hardening checklist covers it.
• Point a subdomain such as n8n.example.com at the server's IP and install Docker Engine with the Compose plugin from Docker's repository.
• Run n8n, Postgres and a reverse proxy such as Caddy that handles TLS. Never publish port 5678 to the internet.
• Set N8N_ENCRYPTION_KEY yourself before the first boot and store a copy off the server. Set N8N_WEBHOOK_URL and N8N_PROXY_HOPS=1, or webhooks will register with the wrong URL.
• Pin the n8n image to a version tag instead of latest, and read the release notes before you bump it.

Every Devoster VPS includes nightly backups kept for 3 days and one snapshot slot. Take a snapshot right before an n8n upgrade, so a failed database migration costs you a rollback instead of an evening. Panel snapshots are removed automatically after 7 days. Keep your own pg_dump and a copy of the data volume off the server too; a backup that lives only with your host covers fewer failure modes.

n8n is source-available, not open source. It ships under the Sustainable Use License, and n8n's documentation summarises it this way: you may use and modify it for your own internal business purposes or for non-commercial or personal use; you may distribute it only free of charge for non-commercial purposes; and you may not remove its licensing notices.

In practice that means running n8n on a VPS to automate your own company's work is allowed, and so is charging for consulting or support around n8n. What n8n lists as not allowed without a separate commercial agreement is hosting n8n and charging people to access it, or white-labelling it for your customers. Renting a server from Devoster doesn't change any of that: we sell you the machine, not an n8n licence. This is a plain-language summary, not legal advice; if your use case sits near the line, read the licence and ask n8n.

• Nobody on the team works in a Linux shell. OS patches, Docker and n8n upgrades, TLS and backups are yours on an unmanaged VPS. If that work won't happen, n8n Cloud is the safer buy.
• Your volume is low. A few hundred executions a month rarely justifies a server plus your time.
• You need SSO, projects or shared credentials across a team. Those are paid n8n features, so you pay n8n either way and the hosting question becomes secondary.
• You want to resell n8n access. That needs a commercial agreement with n8n first, whatever server it runs on.
• Your data has to stay outside the US. Devoster VPS servers are in Utah, USA. For automation the distance rarely matters to performance, but it may matter to your compliance requirements.

If none of those apply, compare the full Devoster VPS plans and start with Starter.