How to Self-Host n8n on a VPS with Docker in 2026 (and When It Beats Zapier or Make)
Self-hosting n8n means renting a small Linux server, running the official Docker image on it, and pointing a domain at the result. You get unlimited workflow executions, your credentials stay in a database you control, and the monthly bill is a VPS instead of a task quota. You also inherit uptime, backups, TLS renewal, and security patching. This guide covers sizing, install, hardening, and the honest break-even math against Zapier and Make.
How this guide was researched
Everything here is desk research, not a hands-on test. We pulled prices, version numbers, and installation commands from the vendors’ own documentation and pricing pages on 2026-10-08. We did not rent a VPS, run Docker, or screenshot a live instance, so treat this as a source-verified procedure rather than a lab report.
The sources are canonical and linked in place: n8n’s documentation, n8n’s pricing page, the n8n Community License, Zapier’s pricing page, Make’s pricing page, DigitalOcean’s droplet pricing, and Hetzner Cloud. Where a number came from a vendor page, it appears exactly as published — no rounding, no “about $20-ish.” At that date, n8n’s current stable release was 2.42.5, and new minor versions ship most weeks.
Why self-host n8n at all (lock-in and metering)
Self-hosting n8n removes per-step metering and keeps your workflow data on hardware you rent. n8n meters whole workflow executions, while Zapier bills every step plus every external connector call as a task and Make bills each module action as a credit. At ten steps per run, that gap compounds fast.
That metering difference is the whole argument. A workflow with ten steps that runs 300 times a month is 300 n8n executions on a server you already pay for. The same workflow is roughly 3,000 Zapier tasks and 3,000 Make credits, because every step and connector call is billed individually. Zapier’s AI steps, code steps, and SDK steps now draw from that same task model, so there’s no separate bucket to hide in.
The second argument is lock-in. Self-hosted n8n stores workflows and credentials in a database file inside a Docker volume. You can copy that volume, export workflows, run them elsewhere, or keep them running if you stop paying anyone. The trade-off is real: you are now responsible for a service other people’s work depends on.
One caveat worth stating plainly, because a lot of tutorials skip it: n8n is not OSI open source. It ships under the Sustainable Use License, a fair-code license created in 2022. You may self-host it free for internal business purposes. You may charge for consulting or building workflows on it. You may not distribute n8n commercially or run it as a hosted service for other people, and the .ee. enterprise files require a paid license.
What you need before you start
You need a small Linux VPS, a domain or subdomain, SSH access, and comfort copying commands into a terminal. Docker handles the rest. Budget 30 to 45 minutes for a clean first install, plus ongoing time for updates, backups, certificate renewal, and security — that part never goes away.
The concrete checklist:
- A VPS account with a provider like DigitalOcean or Hetzner Cloud, and one server created with an Ubuntu or Debian image.
- A domain or subdomain (for example
n8n.yourdomain.com) with an A record pointing at the server’s IP. Needed for HTTPS. - An SSH key pair. Most providers let you paste the public key at server creation, which is safer than password login.
- A terminal on your own machine, and the ability to paste commands without retyping them.
- A password manager entry reserved for your
N8N_ENCRYPTION_KEYand database backups. - A decision about backups: provider snapshots, a scheduled volume archive, or both.
Choosing a VPS: what it actually costs
A lean n8n-only container runs comfortably in 1–2 GB of RAM, so a $6/month DigitalOcean droplet is the usual starting point. The full official compose stack — n8n plus the Assistant sandbox, SearXNG, and runners — needs at least 4 GB RAM and 2 vCPUs, which changes the arithmetic.
| Provider / plan | Verified specs | Price | Verdict |
|---|---|---|---|
| DigitalOcean Basic | 512 MB RAM, 1 vCPU | $4/mo | Testing only. Too tight for real workflows. |
| DigitalOcean Basic | 1 GB RAM, 1 vCPU, 25 GB disk | $6/mo | The sweet spot for a lean n8n-only container. |
| DigitalOcean Basic | 2 GB RAM, 1 vCPU, 50 GB disk | $12/mo | Headroom for heavier workflows with many concurrent executions. |
| DigitalOcean Basic | 2 GB RAM, 2 vCPU | $18/mo | Best fit if you want the full Docker-in-Docker sandbox stack on DigitalOcean. |
| Hetzner Cloud shared (Regular Performance) | 1 vCPU, 20 TB traffic | from €5.99/mo, excl. VAT | Strongest price-per-resource; prices exclude VAT, and check locations. |
Two billing notes. DigitalOcean moved to per-second billing on January 1, 2026, so a server you delete an hour after testing costs cents, not a month. Hetzner Cloud’s shared plans start at €5.99/month excluding VAT, which is a different number than a US reader might expect after tax.
Don’t over-provision on day one. You can resize a droplet later in most providers, and n8n’s own docs treat a single container as the lightweight path. The 512 MB tier will build and start n8n, but you will feel it the first time a large workflow runs.
Installing n8n with Docker, step by step
There are two install paths and both use the same pieces: the n8nio/n8n image, the n8n_data:/home/node/.n8n volume, and port 5678. The one-line setup gets you running in a minute; a compose file is what you actually want for a server you plan to keep.
1. Create the server and log in. Create the VPS with your SSH key, then connect:
ssh root@YOUR_SERVER_IP2. Install Docker. Use your provider’s Docker-ready image if it offers one, or install Docker from its official install script and verify with docker --version.
3. Create a persistent volume. The volume is where workflows, credentials, and the SQLite database live. Lose it and you lose everything.
docker volume create n8n_data4. Run n8n (one-line setup). n8n’s own quick-start uses a single docker run, and there’s a helper script at get.n8n.io.
docker run -it --rm \
--name n8n \
-p 5678:5678 \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8n:stableUse the stable tag. Pinning a specific minor version means you silently stop receiving fixes and security patches.
5. Or use a compose file (recommended). n8n publishes reference compose files at github.com/n8n-io/n8n-hosting. A minimal, hardened single-container version looks like this:
services:
n8n:
image: docker.n8n.io/n8nio/n8n:stable
restart: unless-stopped
ports:
- "127.0.0.1:5678:5678"
environment:
- GENERIC_TIMEZONE=Europe/Berlin
- TZ=Europe/Berlin
- N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:Generate the encryption key once and store it somewhere safe:
echo "N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)" >> .env
docker compose up -d6. Set your environment variables. GENERIC_TIMEZONE and TZ control schedules and timestamps. N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true restricts permissions on n8n’s config file. And if you’re copying a tutorial from 2024, delete N8N_RUNNERS_ENABLED — it was deprecated from n8n 2.0 and is no longer needed.
7. Optional: switch to Postgres. SQLite is the default and is fine for most single-server installs. If you want a separate database, set DB_TYPE=postgresdb and the connection variables that go with it, then run Postgres as a second service.
8. Create your owner account. Open http://YOUR_SERVER_IP:5678 (or the port mapping you chose) and complete the setup screen. Afterward, move to the next section before putting anything real in it.
Security and HTTPS: the part most guides skip
Expose as little as possible. If you put a reverse proxy in front of n8n, bind the container to 127.0.0.1:5678 and let only ports 80 and 443 reach the internet. Never expose the sandbox runner, its privileged Docker-in-Docker socket, or ports 8080 and 9090.
n8n’s docs recommend self-hosting for expert users, and the reason is this section. Three things to get right:
TLS. Without HTTPS, your login credentials and every API key you paste into n8n travel in plain text. Caddy is the simplest option because it obtains and renews certificates automatically. A two-line Caddyfile is enough:
n8n.yourdomain.com {
reverse_proxy 127.0.0.1:5678
}If you prefer nginx, pair it with certbot. Traefik works too, especially if you’re already running it. Whichever you pick, keep the compose port binding on 127.0.0.1:5678:5678 so the proxy is the only public door.
Firewall. Allow SSH, HTTP, and HTTPS, then drop everything else. On Ubuntu:
ufw allow OpenSSH
ufw allow 80
ufw allow 443
ufw enableIf you skip the reverse proxy entirely, port 5678 is the only port that should be internet-facing — and it should be a temporary state. Never open 8080 or 9090, and never expose the sandbox-runner container, which runs privileged Docker-in-Docker and is effectively a root shell if it leaks.
The encryption key. N8N_ENCRYPTION_KEY encrypts saved credentials in the database. If you lose it, every saved credential becomes unreadable — the workflows survive, the logins inside them don’t. Back it up somewhere separate from the server, and never regenerate it casually.
Updates, backups, and staying alive
Updating n8n is docker pull, stop, remove, and re-run against the same volume — or, with compose, pull, down, and up -d. Back up the volume and your N8N_ENCRYPTION_KEY first: losing that key makes every saved credential in the database unreadable.
The manual container path:
docker pull docker.n8n.io/n8nio/n8n:stable
docker stop n8n && docker rm n8n
# re-run with the same -v n8n_data:/home/node/.n8nWith compose, it’s shorter:
docker compose pull
docker compose down
docker compose up -dThe volume is untouched the whole time. That’s why the volume — not the container — is the thing you protect.
Backups: the simplest reliable approach is a provider snapshot on a schedule. If you’d rather own the archive, tar the volume into a file and copy it off-server, then test a restore at least once. A backup you’ve never restored is a hope, not a backup.
Everything else is ordinary server ownership: monitoring so you learn about downtime before your users do, disk space alerts (SQLite databases and execution logs grow), and certificate renewal, which Caddy and certbot handle for you. If your workflows run payroll, invoices, or customer notifications, decide now who gets paged when the container stops.
Does it actually beat Zapier or Make? The break-even math
On cash, self-hosting wins almost immediately: a $6/month droplet undercuts Zapier Professional at $19.99/month by about $14/month, or roughly $168/year, and undercuts Make Core at $12/month by about $6/month. The metering difference matters more than the sticker price as workflow step counts grow.
| Platform | Entry paid price | Metering unit | Free tier |
|---|---|---|---|
| n8n (self-hosted) | $0 license + VPS from $4–$6/mo | Workflow execution; n8n meters nothing on your own server | n/a — you pay the VPS |
| n8n Cloud | Starter $20/mo billed annually, 2.5K executions; Pro $50/mo, 10K; Business $800/mo, 40K | Full workflow execution, unlimited steps | 14-day trial, no credit card, 1,000 executions, 5 concurrent, 180s timeout |
| Zapier | Professional from $19.99/mo billed yearly, task tiers from 750 up to 100K+; Team from $69/mo | Task — every step and every external connector call | Free: 100 tasks/mo, two-step Zaps only |
| Make | Core $12/mo, 10K credits; Pro $21/mo; Teams $38/mo | Credit — one module action = 1 credit | Free: 1,000 credits/mo, 15-minute minimum interval |
Annual billing on Make saves about 15%. Zapier’s $19.99 entry point is also the annual-billing rate.
The worked example. Take one 10-step workflow, run 300 times a month.
- Self-hosted n8n on a $6 droplet: 300 executions. n8n doesn’t meter steps, so the step count is irrelevant. The droplet also has room for other workflows.
- Zapier: roughly 3,000 tasks — 10 steps × 300 runs. That’s four times the smallest Professional tier of 750 tasks, so it pushes you into a higher task tier than the $19.99 headline.
- Make: roughly 3,000 credits, since each module action is one credit. That fits inside Core’s 10,000 credits at $12/month, with room left over.
So the honest summary: Make is genuinely competitive at this volume and often cheaper than Zapier for the same work. Self-hosting still costs less in cash than both, and the gap widens predictably every time you add a step to the workflow. But the VPS bill is the smaller half of the cost — your maintenance hours are the larger half, and they don’t appear on any pricing page.
If you want n8n’s execution-based metering without running a server, n8n Cloud is the middle path: Starter at $20/mo billed annually covers 2.5K executions with unlimited steps, and a 14-day trial with 1,000 executions needs no credit card. That trial comfortably absorbs the 300-execution example above.
When you should NOT self-host
Skip self-hosting if nobody on your team can own uptime, backups, TLS renewal, and security patching. A business-critical automation running on a server nobody monitors is a liability, not a saving. Managed n8n Cloud, Zapier, and Make all sell you that operational cover.
More specific reasons to stay managed:
- You need a support contract or SLA. Self-hosted n8n comes with documentation and a community forum. That’s it.
- You’d be reselling it. The Sustainable Use License forbids running n8n as a hosted service for other people. If your business model is “automation as a product,” read the license before you build.
- You need enterprise features. The
.ee.files require a paid license regardless of where you host. - Your volume is tiny. If you run two simple Zaps a month, Zapier’s free tier or Make’s 1,000 monthly credits handles it at zero cost, and you skip the server work entirely.
- You can’t debug a container. When n8n won’t start at 2 a.m., someone has to read
docker logs n8n. If that sentence is stressful, self-hosting is the wrong choice. - You want the full sandbox stack without the RAM. The official compose setup with the Assistant sandbox, SearXNG, and runners wants 4 GB RAM and 2 vCPUs. On DigitalOcean that’s the $18 tier, which changes the break-even story.
None of these are disqualifying forever. Many teams start on a managed plan, learn what their workflows actually cost in executions, and migrate to a $6 droplet once the numbers make the case.
FAQ
Is n8n really free to self-host?
Yes, for internal business use. Self-hosting the Community edition costs nothing beyond your VPS, with no execution cap from n8n. But it’s fair-code under the Sustainable Use License, not OSI open source — n8n says so itself. You may offer paid consulting and build workflows for clients, but you may not distribute n8n commercially or run it as a hosted service for others. Enterprise .ee. files need a paid license.
How much RAM does n8n need on a VPS?
A lean n8n-only container runs in 1–2 GB of RAM, which makes DigitalOcean’s $6/month droplet with 1 GB RAM, 1 vCPU, and 25 GB disk a reasonable single-workflow starting point. The full official compose stack — n8n plus the Assistant sandbox, SearXNG, and runners — needs at least 4 GB RAM and 2 vCPUs because the sandbox runs Docker-in-Docker. If you plan to use that stack, size for it up front.
Can I migrate my Zapier or Make workflows over?
Not automatically, and not perfectly — there’s no official importer. You rebuild workflows in n8n’s canvas, which is usually faster than expected because n8n’s nodes map cleanly onto most common Zapier and Make actions. The metering change is the bigger mental shift: n8n counts one execution per workflow run, not one task per step. For a step-by-step rebuild process, see our Zapier to n8n migration guide.