How to Install n8n on a VPS: The Complete 2026 Guide

The short answer: take a VPS with at least 2 vCPU and 4 GB of RAM, point a subdomain at its IP, install Docker Engine and the Compose plugin, then run a four-service stack — n8n, PostgreSQL, a reverse proxy that terminates TLS, and a persistent volume for each. Set N8N_ENCRYPTION_KEY yourself before the first boot, set N8N_WEBHOOK_URL to the exact public hostname, and back up both the Postgres database and the n8n data directory. First time through, that is about 45 minutes of work.

The rest of this guide is the detail that decides whether the instance is still healthy in six months: the licence terms you should read before you deploy, honest sizing, the full Compose stack, the environment variables that actually matter, and the two mistakes that cost people every credential they had stored.

Key Takeaways

• n8n Cloud is priced per workflow execution; a VPS is priced per month regardless of how often your workflows run. One schedule firing every five minutes is roughly 8,600 to 8,900 executions a month on its own, which is where the crossover usually happens.
• n8n is not open source. It ships under the Sustainable Use License, which permits internal business use and forbids hosting n8n and charging people to access it. Read the licence section below before you build anything commercial on it.
• Use PostgreSQL, not the default SQLite. Switching later is not an in-place migration, and n8n's own docs say so.
• N8N_ENCRYPTION_KEY is the single most important value in your stack. Lose it and every stored credential in the database becomes ciphertext you cannot decrypt. Store it in a password manager, not only in the .env file on the server.
• Behind a reverse proxy, n8n will advertise the wrong webhook URL unless you tell it the public one. Set N8N_WEBHOOK_URL and N8N_PROXY_HOPS, or external services will register callbacks that never arrive.
• 1 GB of RAM runs n8n only in the narrowest sense. Add Postgres, a Code node, or any browser-automation work and the Node.js heap runs out.

What Self-Hosting n8n Actually Saves You

The economics are simple, and they are the real reason people search for how to install n8n on a VPS in the first place. n8n Cloud bills on monthly workflow executions. One execution is one full run of a workflow, regardless of how many steps it contains — which is genuinely more generous than the per-step billing most automation tools use, but it still scales with how often your workflows fire.

At the time of writing (September 2026), n8n's pricing page lists Starter at 20 EUR per month billed annually for 2,500 executions, Pro at 50 EUR for 10,000, and Business at 667 EUR for 40,000. Check the page for current numbers; n8n changes them.

Now look at what a schedule costs. n8n's own pricing FAQ works the arithmetic: a daily schedule is 30 or 31 executions a month, and a schedule running every five minutes is about 8,600 to 8,900. That is one workflow. A single five-minute polling loop consumes almost the entire Pro allowance before you have built anything else.

What you are running	Executions per month	Cloud tier you would need	Self-hosted equivalent
Ten workflows on daily schedules	~300	Entry tier is plenty	Cloud is probably cheaper. Stay there.
Webhook receiver taking 300 events a day	~9,000	Mid tier	Roughly break-even, before your time
Twenty workflows on hourly schedules	~14,600	Above mid tier	A single VPS handles this comfortably
One five-minute polling loop plus normal work	~10,000+ from one workflow	Escalates fast	Cost is flat. This is the crossover.

The honest part: a VPS is not free, it is fixed. Our Starter plan is 2 vCPU, 4 GB RAM and 75 GB NVMe at 7.99 dollars a month, and that number does not move when your execution count triples. What does move is your time. Budget an hour or two for the initial build and something like twenty to forty minutes a month afterwards for OS patches, an n8n version bump, and a look at your backups. If that time has no value to you, self-hosting is dramatically cheaper. If you bill by the hour, do the multiplication before you commit.

There is also a category of reason that has nothing to do with money: data residency, workflows that need to reach a private network, credentials you are not willing to store on someone else's platform, and the freedom to install community nodes. Those reasons hold even when the maths does not.

The n8n Licence: Read This Before You Deploy

This gets misreported constantly, so here it is precisely. n8n is not MIT-licensed and n8n does not call itself open source. Its source is available under the Sustainable Use License, with source files containing .ee. in the filename covered by a separate n8n Enterprise License. n8n's own licence documentation explains why: the Open Source Initiative definition does not allow limitations on use, and this licence has them.

The Sustainable Use License grants you the right to use, modify, create derivative works and redistribute, with three limitations, quoted from n8n's documentation:

• You may use or modify the software only for your own internal business purposes, or for non-commercial or personal use.
• You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes.
• You may not alter, remove or obscure any licensing, copyright or other notices of the licensor in the software.

In practice, n8n says all use is allowed unless you are selling a product or service whose value derives entirely or substantially from n8n functionality. Its documentation gives explicit examples of what is not allowed: white-labelling n8n and offering it to your customers for money, and hosting n8n and charging people to access it. Both of those need a separate commercial agreement with n8n.

Things that are allowed, again from n8n's own examples: syncing data your company controls, building an n8n node for your own product, providing paid consulting or support services around n8n, and running it on an internal company server. Using n8n as a back end for a feature in your app is usually fine as long as the process does not collect your users' own third-party credentials.

On editions: the free Community edition includes almost the whole feature set. Registering your email unlocks a free Registered Community edition with a few extras. Paid Business and Enterprise plans unlock SSO, projects, environments, external secrets, log streaming, multi-main mode and workflow or credential sharing. That last one surprises people — on Community edition, only the instance owner and the user who created a workflow or credential can access it.

This is a plain-English summary of a plain-English licence, not legal advice. If your use case sits anywhere near the line, read the licence text and email n8n rather than guessing.

Best VPS for n8n: Honest Sizing

Three processes have to coexist: the n8n Node.js application, PostgreSQL, and a reverse proxy. The proxy is negligible. Postgres on a small instance is modest. n8n is the one with an appetite, and its appetite is bursty rather than constant — idle for an hour, then a workflow pulls 8,000 rows into memory at once.

n8n's documentation is direct about the failure mode: workflow memory usage rises with the volume of JSON data, the size of binary data, the number of nodes, and the use of the Code node, and manual executions cost extra because n8n copies the data for the front end. When it runs out you get Allocation failed - JavaScript heap out of memory in the logs. The Docker image restarts n8n automatically when this happens, which is a mercy and also why some people never notice their instance is undersized — they just see occasional failed executions.

For reference, n8n's own Docker Compose install guide asks for at least 4 GB of RAM and 2 vCPUs for the stack it documents, which includes the Assistant sandbox. Plain n8n plus Postgres needs less than that, but it tells you where the vendor's comfort line sits.

Devoster plan	Specs	Price	Honest verdict for n8n
Nano	1 vCPU / 1 GB / 25 GB NVMe	3.49 USD	Testing and learning only. With Postgres alongside n8n you are one Code node away from an out-of-memory restart.
Micro	1 vCPU / 2 GB / 50 GB	4.49 USD	The realistic floor. Fine for a personal instance with a handful of light schedules and a swap file configured.
Starter	2 vCPU / 4 GB / 75 GB	7.99 USD	Recommended starting point for anything you rely on. Room for Postgres, execution history and the occasional heavy run.
Basic	3 vCPU / 6 GB / 100 GB	10.99 USD	Several concurrent executions, larger payloads, longer retention of execution data.
Advanced	4 vCPU / 8 GB / 125 GB	13.99 USD	Where queue mode starts to make sense: Redis plus one or two worker processes on the same box.
Pro	6 vCPU / 12 GB / 150 GB	19.99 USD	Queue mode with several workers, or workflows that drive a headless browser. Chromium is not a light guest.

Two sizing notes people learn the hard way. First, queue mode multiplies memory, not just CPU: each worker is its own full Node.js process, and it also requires Redis. Second, disk fills from execution history, not from the application. n8n saves execution data by default, and a chatty instance can add gigabytes of Postgres rows in a month. There is a pruning section further down; read it before you run out of space rather than after.

If you are still choosing hardware generally, our breakdown of what cheap VPS hosting actually buys you in 2026 covers the corners budget providers cut, and how many workloads a VPS can really hold applies the same maths to stacking services on one box.

Before You Write Any YAML

Four things need to be true before Docker Compose will produce a working instance.

1. DNS resolves. Create an A record for something like n8n.example.com pointing at your VPS IPv4, and an AAAA record if you have IPv6. Wait until it actually resolves from outside. The reverse proxy will request a certificate over HTTP-01, and that fails if the name does not yet point at the box.
2. The firewall allows 80, 443 and your SSH port, and nothing else. Specifically, do not open 5678. n8n should only ever be reachable through the proxy.
3. Docker Engine and the Compose v2 plugin are installed from Docker's official repository, not the distribution's older package. Confirm with docker compose version.
4. You are not working as root. Create a normal user with sudo, then add it to the docker group — and understand that membership of the docker group is effectively root on the host. Our VPS security hardening checklist covers the SSH keys, firewall and automatic updates that should be done first.

On a 2 GB plan, add a swap file before you start. It will not make n8n fast, but it stops the kernel out-of-memory killer from choosing Postgres as its victim during a spike.

The n8n Docker Compose Deployment

Create a directory, for example /opt/n8n, owned by your non-root user. Three files go in it: .env, compose.yml and Caddyfile.

Step 1: the .env file

Generate the encryption key and the database password with real randomness — openssl rand -hex 32 for the key, openssl rand -base64 24 for the password. Then write these lines, one per line, into .env:

POSTGRES_USER=n8n
POSTGRES_PASSWORD=paste-the-generated-password
POSTGRES_DB=n8n
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=paste-the-same-password
N8N_ENCRYPTION_KEY=paste-the-generated-key
      

Then lock it down: chmod 600 .env. Compose reads this file for both container environment and its own variable substitution, so it holds every secret in the stack.

Step 2: compose.yml

Three top-level keys: a project name, the named volumes, and the services. The environment block on the n8n service is explained variable by variable in the next section.

name: n8n

volumes:
  n8n_data:
  db_data:
  caddy_data:
  caddy_config:

services:
  postgres:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER
      - POSTGRES_PASSWORD
      - POSTGRES_DB
      - PGDATA=/var/lib/postgresql/data
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
      interval: 5s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.38.7
    restart: unless-stopped
    env_file: .env
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_EDITOR_BASE_URL=https://n8n.example.com/
      - N8N_WEBHOOK_URL=https://n8n.example.com/
      - N8N_PROXY_HOPS=1
      - GENERIC_TIMEZONE=Asia/Jerusalem
      - TZ=Asia/Jerusalem
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
    volumes:
      - n8n_data:/home/node/.n8n
    expose:
      - 5678
    depends_on:
      postgres:
        condition: service_healthy

  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - n8n
      

Pinning PGDATA is not optional decoration. Postgres 18 changed its default data directory, and n8n's documentation warns that without that line the volume mount no longer covers the data and your database comes up empty.

Step 3: the Caddyfile

Three lines:

n8n.example.com {
  reverse_proxy n8n:5678
}
      

Caddy obtains and renews the certificate automatically, redirects HTTP to HTTPS, and — importantly for n8n — sets X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Host by default, which is exactly what n8n asks for behind a proxy. If you prefer Nginx or Traefik, that is fine; you will just be setting those three headers yourself.

Step 4: bring it up

Run docker compose up -d, then docker compose ps and wait for postgres to report healthy. Watch the first boot with docker compose logs -f n8n. Then open your hostname in a browser. If Caddy is still fetching a certificate you may get a brief TLS error; give it thirty seconds.

The Environment Variables That Actually Matter

These go in the n8n service's environment block. This is the part most guides get subtly wrong, because n8n renamed things and old blog posts never caught up.

Variable	Value	Why it matters
DB_TYPE	postgresdb	Switches off the built-in SQLite. Without this nothing else in the Postgres block does anything.
DB_POSTGRESDB_HOST / DB_POSTGRESDB_PORT	postgres / 5432	The host is the Compose service name, not localhost.
N8N_HOST	n8n.example.com	Host name n8n runs on. Defaults to localhost.
N8N_PROTOCOL	https	Defaults to http. Feeds the URLs n8n generates.
N8N_EDITOR_BASE_URL	https://n8n.example.com/	Public URL of the editor. Also used in outbound emails and as the SAML redirect URL.
N8N_WEBHOOK_URL	https://n8n.example.com/	Base URL for production and test webhooks behind a proxy. This replaced WEBHOOK_URL, which is deprecated from n8n 2.35.0 — the old name still works but logs a deprecation warning.
N8N_PROXY_HOPS	1	Number of reverse proxies in front of n8n. Without it, forwarded headers are not trusted.
GENERIC_TIMEZONE	e.g. Asia/Jerusalem	Timezone used by the Schedule Trigger and other time-based nodes. Default is America/New_York.
TZ	the same value	System timezone inside the container, so logs and shell commands agree with your schedules.
N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS	true	Forces 0600 on the settings file that holds the encryption key.
N8N_ENCRYPTION_KEY	your generated key	See the next section. This one has no second chances.

One more piece of stale advice worth killing: N8N_RUNNERS_ENABLED=true appears in almost every n8n tutorial written for version 1.x. It is deprecated from n8n 2.0 and you no longer need to set it.

The Encryption Key Warning

If you lose N8N_ENCRYPTION_KEY, every credential stored in your n8n database is permanently unreadable. There is no reset, no support ticket, no recovery. You re-enter every API key, OAuth connection and password by hand.

Here is what actually happens. n8n generates a random encryption key on first launch and writes it into the config file in the .n8n directory. It uses that key to encrypt credentials before storing them in the database. The credentials in Postgres are ciphertext; the key is somewhere else entirely.

That split is where people get hurt. The classic disaster: you take a clean Postgres dump every night, feel responsible, then rebuild the server after an incident, restore the database — and find every credential broken, because the new container generated a fresh key and the old one lived in a Docker volume nobody backed up.

Three rules that prevent it:

• Set the key explicitly before first boot. If you let n8n generate it, you are depending on a file you may not be watching. Setting it yourself means the value exists in your password manager from minute one.
• Store it somewhere that is not the server. A copy in .env on the VPS is not a backup of the key; it is the same disk that just died.
• In queue mode, every worker needs the identical key. n8n's docs are explicit: the main instance's key must be shared with all worker and webhook processor nodes, or workers cannot decrypt credentials.

Also keep persisting the /home/node/.n8n volume even though you are on Postgres. n8n's documentation notes that the directory still holds the encryption key, instance logs and source control assets. If you ever need to change the key deliberately, n8n documents a rotation procedure — that is the supported path, not editing the database.

Reverse Proxy, TLS, and Why Webhooks Silently Break

This is the most common "it works but it doesn't" problem when you self-host n8n, and the cause is mechanical. n8n builds its webhook URL by combining N8N_PROTOCOL, N8N_HOST and N8N_PORT. Behind a proxy, n8n listens internally on 5678 while the world talks to 443 — so the URL it constructs is wrong, and the URL it shows you in the editor is the one you copy into Stripe, GitHub or Typeform.

The service then POSTs to an address that does not exist publicly. No error appears in n8n, because n8n never receives the request. You sit there re-saving the workflow.

Use this to diagnose:

• If the editor shows a webhook URL containing localhost or :5678, then N8N_WEBHOOK_URL is missing or wrong. It must be the exact public base URL, including the scheme.
• If the URL looks right but the third-party service reports a redirect loop or an SSL error, then check that the proxy terminates TLS and forwards to n8n over plain HTTP inside the Docker network, not back to itself.
• If requests arrive but n8n logs the proxy's IP as the client, then N8N_PROXY_HOPS is not set to 1.
• If you can load the login page but the session never sticks, then you are probably reaching n8n over plain HTTP or by raw IP. N8N_SECURE_COOKIE defaults to true, so the auth cookie is only sent over HTTPS.
• If everything works on the main domain but breaks under a subpath, then reconsider. n8n's docs warn that combining N8N_PATH with a reverse proxy causes navigation problems, and recommend a dedicated subdomain instead.

First Login, Users and Access

There is no default username. On first visit you create the instance owner account in the browser — email, password, done. The old N8N_BASIC_AUTH_ACTIVE pattern that older tutorials still recommend is no longer part of the current configuration; user management is the mechanism now.

Turn on two-factor authentication for the owner account immediately, from the user settings menu. MFA is available by default, and if you run a team instance you can require it for everyone with N8N_MFA_ENFORCED_ENABLED.

Set expectations about sharing before you invite colleagues: on the free Community edition, only the instance owner and the user who created a workflow or credential can access it. Sharing workflows and credentials between users is a paid-plan feature. For a solo operator this is irrelevant; for a three-person team it is the thing that decides whether self-hosting works for you.

Backups and a Restore Drill

Two things must be backed up, and most people only do one.

1. The Postgres database — workflows, credentials (encrypted), execution history, users. Dump it with docker compose exec -T postgres pg_dump -U n8n -Fc n8n redirected to a dated file.
2. The n8n data volume — the encryption key and instance settings. Archive it with a throwaway container: docker run --rm -v n8n_n8n_data:/data -v /opt/backups:/backup alpine tar czf /backup/n8n-data.tgz -C /data . Run docker volume ls first to confirm the volume's real name, since Compose prefixes it with the project name.

Copy both off the server. A backup on the same VPS protects you against exactly one failure mode — your own mistakes — and none of the others.

The restore drill. Put it in your calendar quarterly, because an untested backup is a hypothesis. Spin up a second small VPS, install Docker, copy the same compose.yml and Caddyfile, use a throwaway hostname, restore the volume archive, bring up Postgres alone, restore the dump with pg_restore, then start n8n. Log in with your existing credentials, open a workflow that uses a stored API key, and execute it. If the credential decrypts and the call succeeds, your backup is real. Destroy the test VPS afterwards.

Upgrades: Pin the Tag, Read the Notes

Do not run :latest. n8n releases a new minor version most weeks — at the time of writing the current stable is 2.38.7 — and latest means an unattended docker compose pull can move you across a breaking change while you are asleep.

The upgrade routine that works:

1. Read the n8n release notes for every version between yours and the target, not just the target.
2. Take a fresh Postgres dump and volume archive. Database migrations run automatically on startup and are not designed to be reversed.
3. Edit the pinned tag in compose.yml, then docker compose pull n8n and docker compose up -d n8n.
4. Watch docker compose logs -f n8n through the migration. Then run one real workflow manually before you walk away.

Postgres major versions are a separate job. You cannot simply bump the image tag: Postgres refuses to open a data directory written by an older major and fails with an incompatibility error. Dump with pg_dumpall first and follow the official PostgreSQL upgrade guide. Your data is not lost when this happens, but your evening is.

Stopping the Database From Eating Your Disk

n8n saves execution data by default. Pruning is on by default too, but the defaults are generous: executions are kept for 336 hours and up to 10,000 of them. On a busy instance with large payloads that is a lot of Postgres.

Tighten it with EXECUTIONS_DATA_MAX_AGE (hours) and EXECUTIONS_DATA_PRUNE_MAX_COUNT. If you do not need successful runs recorded, EXECUTIONS_DATA_SAVE_ON_SUCCESS=none is the single biggest saving — keep errors, drop the noise. Two related traps: manual executions are saved by default and are the largest ones you will generate, and queue mode does not support filesystem binary-data storage, so large-file workflows need S3-compatible external storage instead.

Set a disk alert at 75 percent. n8n does not fail gracefully when Postgres cannot write.

Hardening After It Is Running

Everything general — SSH keys, disabling password login, a default-deny firewall, Fail2ban, unattended upgrades — is in our VPS security hardening checklist, and it applies here unchanged. The n8n-specific additions are short:

• Never publish port 5678 to the host. If docker compose ps shows it bound to 0.0.0.0, fix that before anything else.
• Set N8N_BLOCK_ENV_ACCESS_IN_NODE=true so expressions and the Code node cannot read your environment variables — which is where your database password lives.
• Use N8N_RESTRICT_FILE_ACCESS_TO to limit which directories workflows can touch.
• Review n8n's SSRF protection settings if untrusted input ever reaches an HTTP Request node.
• Treat community nodes as third-party code running with your instance's privileges, because that is what they are.

When Self-Hosting n8n Is the Wrong Call

Plainly: if nobody on your team is comfortable in a Linux shell, buy n8n Cloud. Devoster VPS plans are unmanaged with full root access, which means OS patching, Docker upgrades, TLS renewals and backups are yours. That is the trade you are making for the flat price, and it is a bad trade if the work will not get done.

Cloud also wins if your volume is genuinely low — a few hundred executions a month will never justify a server plus your attention. And if you need enterprise features like SSO or projects, you are paying n8n either way, so the infrastructure question becomes secondary.

Self-hosting wins when execution volume is high or growing unpredictably, when data must stay on infrastructure you control, when workflows need to reach private services, or when you want full freedom over versions and community nodes.

If you have read this far and the trade looks right, the practical path is: order a 2 vCPU / 4 GB VPS, point a subdomain at it, spend forty-five minutes on the stack above, and put a calendar reminder for your first restore drill. Knowing how to install n8n on a VPS properly is mostly about the four things nobody puts in the quickstart — Postgres instead of SQLite, a key you control, a webhook URL that matches reality, and a backup you have actually restored.

Frequently Asked Questions

How much RAM does n8n need on a VPS?

For a production instance running n8n plus PostgreSQL plus a reverse proxy, 4 GB is a comfortable starting point and 2 GB is a workable minimum with swap configured. Memory use is driven by the size of the data a workflow holds at once, not by how many workflows you have, so one badly batched workflow can outgrow a large server.

Can I run n8n on a 1 GB VPS?

It will start, and a couple of light schedule-driven workflows may run fine for months. But add PostgreSQL, a Code node processing a few thousand items, or any browser automation and you will hit JavaScript heap errors. Use 1 GB for learning and testing; move to 2 GB or more for anything you depend on.

Is self-hosted n8n free?

The Community edition is free and includes almost the complete feature set, and registering your email unlocks a free Registered Community edition with extras like folders and debug in editor. You still pay for the server. Paid Business and Enterprise plans add SSO, projects, environments, external secrets and workflow sharing.

Can I sell access to my self-hosted n8n instance?

No. n8n's Sustainable Use License restricts use to your own internal business purposes, and n8n's documentation names hosting n8n and charging people to access it, and white-labelling it for customers, as examples that are not allowed. Paid consulting and building workflows for clients are allowed. Anything resembling resale needs a commercial agreement with n8n.

Why do my n8n webhooks show the wrong URL?

Because n8n builds the URL from its internal protocol, host and port, which are not what the outside world sees behind a reverse proxy. Set N8N_WEBHOOK_URL to your public base URL and N8N_PROXY_HOPS to 1, and make sure the proxy forwards X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto. Note that the older WEBHOOK_URL name is deprecated from n8n 2.35.0.

Do I really need PostgreSQL, or is SQLite fine?

SQLite is fine for trying things out and n8n uses it by default. It bites later: concurrent writes are the weak point, the file grows with execution history, and n8n's docs state that switching to Postgres does not migrate existing SQLite data automatically. Starting on Postgres costs you five extra lines of YAML on day one instead of a manual rebuild on day two hundred.