How to Self-Host n8n: Step-by-Step Guide

Updated 2026-09-09 · 1233 words

This page may contain affiliate links. If you buy through them we may earn a commission at no extra cost to you.

Direct answer: self-hosting n8n reliably means Docker Compose, Postgres instead of the default SQLite, a reverse proxy for HTTPS, and correctly set webhook environment variables before you wire up a single trigger. On a $6–$12/month VPS this takes under an hour if you follow the steps in order, and it's the setup we run in production today. Skip any one of these four pieces and you'll hit a wall within your first week, usually a webhook that silently doesn't fire or a database file that doesn't survive a container restart.

Step 1: Size your server

n8n itself is light. A 1GB RAM / 1 vCPU VPS runs it fine for testing, but we'd size up to 2GB for anything you plan to actually rely on, especially once you add Postgres and a handful of AI-agent workflows that hold LLM API calls open for several seconds at a time. Hetzner, DigitalOcean, and Vultr all sell a 2GB box in the $6–$12/month range, and any of them worked identically in our testing. Pick whichever region is closest to your team and your most-used APIs to keep webhook latency low.

Skip anything under 1GB RAM. n8n's Node.js process plus Postgres will swap constantly on a 512MB box, and you'll spend more time debugging mysterious slowness than you saved on hosting cost.

Step 2: Install Docker and write the Compose file

Install Docker and the Compose plugin on a fresh Ubuntu or Debian server (n8n's own docs keep an up-to-date one-liner for this; we won't reproduce install commands here since they change with each Docker release). Then write a docker-compose.yml with two services: Postgres and n8n. Point n8n at Postgres with DB_TYPE=postgresdb and the matching DB_POSTGRESDB_* variables, and give Postgres a named volume so its data survives container recreation.

Starting on the default SQLite database feels faster on day one, but it's a decision you'll regret the first time you need to move to a bigger server or add a second n8n instance. Postgres from the start costs you fifteen extra minutes of Compose config and saves you a live-data migration later. If you just want the Docker mechanics on their own, our guide to running n8n with Docker covers the quick single-container command, image versioning, and volume permissions in more depth than this step needs.

Step 3: Set the webhook and host variables correctly

This is the step that trips up almost everyone on their first self-hosted n8n deploy. Set N8N_HOST to your actual domain, N8N_PROTOCOL=https, N8N_PORT=5678 (n8n's internal port, not necessarily what you expose publicly), and WEBHOOK_URL to the full public HTTPS URL n8n should hand out for webhook nodes. If you skip WEBHOOK_URL, n8n defaults to constructing webhook addresses from its container's internal view of itself, and every webhook-triggered workflow you build will show a URL that no external service can actually reach. We lost an afternoon to this exact mistake the first time we deployed n8n behind a reverse proxy, and it's the single most common self-hosting complaint in n8n's own community forum.

Step 4: Put a reverse proxy in front of it for HTTPS

Don't expose n8n's raw port 5678 to the internet. Run Caddy or Nginx in front of it instead, terminate TLS there, and proxy requests through to the n8n container over your Docker network. Caddy is the simpler option if you want automatic Let's Encrypt certificate management with almost no config; a five-line Caddyfile pointing your domain at the n8n container is enough for most single-instance setups. Nginx gives you more control if you're already running other services on the same box and want everything behind one config.

Firewall the server so only ports 80 and 443 are reachable externally. n8n's own port should only be reachable from the reverse proxy container, never directly from the public internet.

Step 5: Secure the owner account and lock down credentials

On first launch, n8n prompts you to create an owner account with an email and password rather than the old HTTP basic-auth prompt from earlier versions. Use a real password manager here; this account has access to every credential you'll ever store in the instance, including API keys for whatever CRMs, email providers, and LLM APIs your workflows touch. If you're running n8n for a team, add individual user accounts rather than sharing the owner login, and use n8n's built-in role permissions to limit who can edit production workflows versus who can only view executions.

Step 6: Set up backups before you build anything real

Your workflows, credentials, and execution history all live inside the Postgres database, not in the n8n container's filesystem. A nightly pg_dump of the Postgres volume, shipped somewhere off the server (even a simple cron job pushing to object storage), is the minimum viable backup strategy. We've seen teams lose weeks of workflow-building work to a botched server migration because they were backing up the wrong directory. Test your restore process once, on a throwaway VPS, before you trust it.

Cloud vs. self-hosted at a glance

When NOT to self-host n8n

Skip self-hosting if nobody on your team is willing to own server updates, TLS renewal checks, and backup verification as an ongoing responsibility, however small. A neglected self-hosted instance that silently falls behind on security patches is worse than paying for n8n Cloud and never thinking about the server again. It's also not worth the setup time if you're only running one or two simple workflows; the maintenance overhead outweighs the savings until you're running enough automation that the per-task math starts to matter.

Common pitfalls to avoid

Beyond the webhook URL issue in Step 3, the next most common mistake is running n8n on the default SQLite database past the testing phase, which works fine until a container restart or an update migration corrupts a file that was never designed for concurrent production writes. The third is forgetting to pin your n8n Docker image to a specific version tag; pulling latest on every restart means an unannounced breaking change can hit your production workflows with zero warning. Pin a version, read the release notes, and upgrade deliberately.

Next steps

Once your instance is stable, our n8n vs Activepieces comparison is worth a look if you're still deciding whether n8n is the right self-hosted platform for your team, and our roundup of self-hosted Zapier alternatives covers six other options if you want a broader picture before committing infrastructure time. If your workflows lean heavily on AI agents rather than general SaaS automation, our Flowise vs n8n comparison covers a purpose-built alternative worth knowing about. And if the open-source licensing details matter for your procurement policy, our breakdown of open source automation tools covers exactly which tools are OSI open source versus fair-code, n8n included.

With Postgres, the right environment variables, and a reverse proxy in place, a self-hosted n8n instance is stable enough to run real business workflows, and the fixed monthly VPS cost stays flat no matter how much you automate on top of it.

Save this to Pinterest