How to run n8n on a VPS in 2026: the complete setup

What a VPS actually buys you

n8n Cloud prices executions. A VPS prices a machine. That is the whole argument: once your workflows fire more than a few thousand times a month, you stop paying for a quota and start paying for a server that doesn't care how often the triggers run. The plan-by-plan math is here, and the crossover sits around 2,500 executions.

What the $5 doesn't cover is the part nobody puts in the comparison table: TLS certificates that renew, version upgrades that occasionally break things, backups you have actually restored once, and something that notices when the box goes down at 3am. Budget roughly an hour a month, more in the first week.

This guide is the full setup — both routes, the sizing, the proxy, the firewall, and the five things that go wrong.

Not interested in maintaining a server? The same Community Edition runs on our one-click n8n template with SSL and a custom domain handled. Skip to the last section for the honest comparison.

Sizing: what n8n actually needs

n8n is a Node process plus a database. It is not heavy at rest; it spikes when workflows run, and it spikes hard if a workflow moves large files.

• 1 vCPU / 2 GB RAM — a personal instance, a handful of workflows, nothing concurrent. Works fine.

• 2 vCPU / 4 GB RAM — the comfortable default for a small team with Postgres on the same box. This is what to pick if you don't want to think about it again.

• 1 GB RAM — possible, but add a swap file. Without swap, a workflow that loads a big payload gets the container OOM-killed mid-execution, and the failure looks like a random workflow error rather than a memory problem.

• Disk — 20–40 GB is plenty for the software. The variable is execution history and binary data, which is covered in the gotchas below.

Any mainstream provider works. Hetzner sits at the cheap end, DigitalOcean, Vultr and Linode a few dollars above it. The provider matters less than whether you'll keep the machine patched.

Route A: the one-click image (fastest)

Several VPS providers ship an n8n marketplace image — Contabo, DigitalOcean and Hostinger among them, and Contabo's one-click image now carries n8n 2.0. You pick n8n instead of a bare OS when creating the server, and a few minutes later there is a running instance on an IP address.

What it saves. Installing Docker, writing a Compose file, and the first-boot fiddling.

What it does not save. Everything after that. The image gives you n8n on an IP; you still point a domain at it, get a certificate, decide on Postgres versus SQLite, set the encryption key, configure backups, and own upgrades. A marketplace image is a faster start, not a managed service — which is the misunderstanding that sends people back to Cloud two months later.

One thing to check immediately. Find out what the image set as the database and whether N8N_ENCRYPTION_KEY is defined explicitly. If the key was auto-generated into the data folder and you don't know it, your backups are only restorable onto the same volume.

Route B: manual Docker install on a clean VPS

Thirty to sixty minutes, and you understand every part of it afterwards. Ubuntu LTS assumed.

1. Create a non-root user and lock down SSH

Log in as root once, create a user, add it to sudo, copy your SSH key across, then disable password authentication and root login in /etc/ssh/sshd_config. This is five minutes and it removes the most common way small servers get taken over.

2. Install Docker

Use Docker's official convenience script or the apt repository — not the distro package, which lags. Add your user to the docker group so you're not typing sudo on every command.

3. Point your domain at the server

One A record: n8n.yourdomain.com → the server's IPv4. Do this before requesting a certificate — Let's Encrypt validates over the domain, so DNS has to resolve first. Propagation is usually minutes.

4. Write the Compose file

n8n plus Postgres, with a named volume for each. The full file, the environment variables that matter, and the n8n 2.0 changes that break older examples are in the n8n Docker Compose guide — use that file rather than repeating it here.

One change for the VPS case: bind n8n to localhost instead of publishing it publicly. In the ports section, '127.0.0.1:5678:5678' rather than '5678:5678'. The reverse proxy reaches it locally; the internet cannot.

5. Put Caddy in front of it

Caddy is the shortest path to working HTTPS — it requests and renews Let's Encrypt certificates on its own. The entire config is two lines in /etc/caddy/Caddyfile:

n8n.yourdomain.com {

  reverse_proxy 127.0.0.1:5678

}

Reload Caddy and the certificate is issued within seconds. nginx does the same job with a longer config and a separate certbot cron — fine if you already know nginx, unnecessary work if you don't.

6. Close the firewall

With ufw: allow SSH, allow 80 and 443, deny everything else, enable. Port 5678 stays closed. If you skipped the localhost binding in step 4, this is what stops your n8n from being reachable without TLS on a raw port.

7. Set up backups before you build workflows

Two things to back up: the Postgres database and the n8n_data volume. A nightly pg_dump plus a tar of the volume, pushed off the server to object storage, is enough. Then restore it once onto a throwaway server — an untested backup is a hypothesis, not a backup.

Five things that break n8n on a VPS

1. Port 5678 exposed to the internet

The default Compose file publishes the port on all interfaces. On a laptop that's harmless; on a public IP it means your n8n editor is reachable over plain HTTP, credentials and all. Bind to 127.0.0.1 and let the proxy be the only door.

2. No swap on a small instance

On 1–2 GB machines, a workflow handling a large file can push the container past the limit and get it killed. The symptom is a workflow that fails without a useful error, sometimes taking the whole instance with it. A 2 GB swap file costs nothing and removes the class of problem.

3. Postgres grows and nobody notices

Most guides tell you to enable pruning. It is already on: EXECUTIONS_DATA_PRUNE defaults to true, keeping 336 hours of history and 10,000 executions. The variable that actually fills your disk is EXECUTIONS_DATA_SAVE_ON_SUCCESS, which defaults to all — every successful run stores its full input and output data. On a workflow that fires hourly and moves real payloads, that adds up fast. Set it to none for chatty workflows you don't debug, and lower EXECUTIONS_DATA_MAX_AGE if you don't need two weeks of history.

4. The certificate renews and the webhook doesn't

Caddy renews quietly, so this one usually bites people on nginx setups where certbot's timer was never enabled. The failure is invisible until an integration starts rejecting your webhook for an expired certificate. Check the expiry date once a quarter, or use a monitor that watches it for you.

5. Nothing watches the box

Your scheduled workflows are only as reliable as the machine, and n8n cannot tell you that n8n is down. Run the monitor somewhere else — a self-hosted Uptime Kuma on a different provider, or any external checker hitting the health endpoint.

What it really costs

Honest monthly numbers for one production n8n instance with a custom domain.

• VPS, self-managed: $5–20 for the server, ~$1 amortised for the domain, $0 for Let's Encrypt, $0–5 for backup storage. Cash: $6–26/month, plus your time.

• VPS from a one-click image: the same, minus about half an hour of setup on day one. The ongoing maintenance is identical.

• Managed n8n specialist: Elestio starts around $11/month for n8n with backups, SSL, updates and monitoring included; Sliplane's smallest server is €9/month and runs as many containers as fit, with managed Postgres priced separately from €19.

• livemy.app: $10/month flat on Maker — the n8n template, custom domain and SSL included, backups a $5 add-on, no execution meter.

• n8n Cloud: €20/month for 2,500 executions, €50 for 10,000, then €667. No server, no maintenance, a meter.

The spread between the cheapest VPS and a managed host is roughly $5–15 a month. Whether that is a good trade depends entirely on what an hour of your attention is worth and how you feel about being paged.

Who should actually run their own VPS

Run the VPS if you're comfortable in a terminal, you already maintain a server for something else, or you need root — system packages alongside n8n, a custom binary a workflow shells out to, a database you also use for something else. That last case is the honest reason to pick a VPS over a managed host, and no comparison table mentions it.

Don't run the VPS if n8n is the only reason you'd have a server. You're taking on the full maintenance surface of a machine to save ten dollars, and the first upgrade that goes sideways costs more than a year of the difference. In that case use a managed host — ours is the one-click n8n template at $10/month flat, and it deliberately does not give you shell access, which is the trade. If you're weighing the options rather than committed, the full provider comparison is here.

FAQ

What size VPS do I need for n8n?

1 vCPU and 2 GB RAM runs a personal instance comfortably. 2 vCPU and 4 GB is the sensible default for a small team with Postgres on the same machine. On 1 GB, add a 2 GB swap file or workflows handling large payloads will get OOM-killed.

What is the easiest way to deploy n8n on a VPS?

A provider's one-click n8n image is the fastest start — Contabo, DigitalOcean and Hostinger all offer one. It gives you a running instance in minutes, but you still handle the domain, the certificate, the encryption key, backups and upgrades yourself. If you want none of that, a managed n8n host removes the server entirely; if you want to understand your own setup, the manual Docker Compose route above takes under an hour.

Do I need Nginx, or is Caddy enough?

Caddy is enough, and it is less work: two lines of config and it handles Let's Encrypt issuance and renewal itself. Choose nginx if you already run it or need something specific from it — you'll also need certbot and a renewal timer.

Can I run n8n on a VPS without Docker?

You can install it via npm, and you'll regret it. Docker pins the Node version n8n expects, keeps upgrades to a pulled image, and isolates the process from the rest of the box. The npm route means managing Node versions by hand on every upgrade.

How do I keep n8n updated on a VPS?

Back up the database and volume, docker compose pull, docker compose up -d, then test one webhook and one scheduled workflow. Read the breaking-changes notes for major versions — the 1.x to 2.x jump dropped MySQL support and removed several environment variables, and that one needs a plan rather than a pull.

Is a VPS cheaper than n8n Cloud?

On cash, yes, and by a lot at volume: $6–26/month against €20–667. On total cost it depends on your time. Below roughly 2,500 executions a month Cloud usually wins on effort; above it the VPS wins on money, and the question becomes whether you want to own a server.

Run it well, or don't run it

A VPS gives you n8n with no execution meter for the price of a coffee. The setup is an hour; the ownership is forever. Do it properly — non-root user, closed firewall, proxy with automatic certificates, tested backups, external monitoring — or use a managed host and spend the hour on workflows instead.

→ Deploy the n8n template on livemy.app · Community Edition, no execution meter · Custom domain and SSL on Maker at $10/month flat · Backups add-on $5/month.

Migrating an existing VPS instance and worried about the encryption key? Email hello@livemy.app before you move anything. Replies inside one business day.

Read next

• n8n with Docker: the Compose file that actually works in 2026

• n8n hosting providers compared in 2026

• How to self-host n8n in 2026: the complete guide

• n8n pricing explained: Cloud vs self-hosted

• How to self-host Uptime Kuma: free monitoring and status page