Disclosure: this piece contains affiliate links. If you sign up through them, I earn a commission at no extra cost to you.

n8n 3.0 shipped as a beta on 27 October 2026. Stable is planned for early December, with no exact day given, and 1.x support ends 31 December 2026. The upgrade is one way — there is no going back to 2.x except by restoring a backup.

The part that changes how you host it is short: npm and npx installs are no longer supported in 3.0. Self-hosted n8n runs on Docker, Kubernetes or Helm. If you run npx n8n or npm install -g n8n today, you move to Docker before you upgrade, not after. Do it after, and you are debugging a broken install with no working n8n underneath it.

This is the setup I would use: a small Vultr VPS, Ubuntu 24.04, Docker Compose, and the official image. No payout figure here — I have not verified the Vultr referral amount in the dashboard, so I am not printing one.

Before you touch anything

  1. Back up ~/.n8n first. That folder holds your encryption key, credentials and instance data. Copy the whole directory, hidden files included. Lose the key and your saved credentials become unreadable.
  2. Set the encryption key before first boot. Put N8N_ENCRYPTION_KEY in your .env and back it up somewhere durable. If n8n generates one inside a volume you later discard, the credentials in that volume are gone with it.
  3. Run the Migration Report on 2.x first. Every instance on 2.39 or later has one under Settings > Migration Report. Update to the latest 2.x, run it, and fix what it flags. If you are still on 1.x, there is no direct path to 3.x — go to 2.x first.
  4. Fix the removed nodes before the upgrade. Cron and Interval become Schedule Trigger. Function and Function Item become the Code node. Workflows with removed nodes look Published after the upgrade and never run — no error, no log, nothing for an error handler to catch. The full list and the replacements are in the 3.0 guide: https://whoisalfaz.me/blog/how-to-upgrade-to-n8n-3-without-breaking-workflows/

The setup

Spin up a Vultr VPS with Ubuntu 24.04 and point a subdomain at it, for example n8n.yourdomain.com. Install Docker Engine and the Compose plugin, then use the official Compose setup. The short version:

services:
n8n:
image: n8nio/n8n
restart: always
ports:
- "127.0.0.1:5678:5678"
environment:
- N8N_HOST=n8n.yourdomain.com
- N8N_PORT=5678
- N8N_PROTOCOL=https
- N8N_WEBHOOK_URL=https://n8n.yourdomain.com/
- N8N_PROXY_HOPS=1
- GENERIC_TIMEZONE=Asia/Dhaka
- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:

Three details matter:

  • Bind the port to 127.0.0.1. Docker-published ports bypass UFW rules, so 5678:5678 on its own puts the editor on the public internet. Bound to localhost, only your reverse proxy on the same server can reach it. Put Traefik or Nginx in front for HTTPS.
  • The volume is the instance. n8n_data:/home/node/.n8n holds the SQLite database and the encryption key. Never run docker compose down -v — it deletes the volume and the data with it.
  • Set the webhook URL. Behind a proxy, n8n builds webhook URLs from its internal host and port unless you tell it otherwise. N8N_WEBHOOK_URL is the current name (from 2.30.0); the old WEBHOOK_URL is deprecated and logs a warning.

If you want the fastest path instead of writing the file yourself, n8n ships a one-line installer — curl -fsSL https://get.n8n.io | sh — that checks Docker, writes the config files and starts an instance. I would still read the Compose file it writes before trusting it in production.

One sizing note: the current official Compose setup can run Postgres plus a separate runner container alongside n8n, and that stack wants more RAM than a bare single-container install. If you run the light path above — one n8n container on SQLite — a small VPS is enough. If you take the full Postgres + runner stack, size the VPS up and check the RAM note in n8n's Compose docs before you pick a plan.

The upgrade itself

Move first, upgrade second:

  1. Move your existing 2.x instance to Docker on the VPS and confirm every workflow runs there.
  2. Pin the image tag. Do not pull :latest blindly on a production box — pin the version you tested.
  3. Upgrade staging to the 3.0 beta if you want to test it now. Keep production on 2.x until the stable release lands in early December.
  4. On first 3.0 start, n8n renames ~/.n8n/binaryData to ~/.n8n/storage. Expect it; do not treat the renamed folder as a fault.
  5. After the upgrade, watch for silent dropouts for 48 hours. A workflow that looks Published and never fires is the failure this release is known for — build the heartbeat check for it, and the Watchtower for the crashes: https://whoisalfaz.me/blog/n8n-global-error-handling/

Who it is for

Self-hosting fits if you want control — custom nodes, your own data, no per-execution billing — and you are willing to patch a server and keep backups. It does not fit if you do not want to maintain a server. Then use n8n Cloud and let someone else run it: https://whoisalfaz.me/go/n8n

That is the honest split on the links, too. The Vultr link is the affiliate in this piece. The n8n link only pays on Cloud signups — a self-hosted install earns nothing from it, and I am not going to pretend otherwise.

The deal, plainly

Vultr through my link: https://whoisalfaz.me/go/vultr — I have not verified the referral amount, so no figure is printed here. n8n Cloud through my link: https://whoisalfaz.me/go/n8n

Move to Docker now, while 2.x still runs. The 3.0 upgrade is a workflow problem and a hosting problem at the same time, and the hosting half is the one you can finish this week.

I build revenue systems for agencies and SaaS. On Alfaz Reviews I test the tools that claim to do the same — AI tools, automation, and free trials: what worked, what broke, and who it is for. Built whoisalfaz.me and fasttools.me.