n8n Self-Hosting Guide: VPS Setup in 20 Minutes

What you need first

You need a VPS with at least a small amount of RAM and disk space, SSH access to it, and Docker installed, since Docker is the most common and best-documented way to run n8n's Community edition. The Community edition itself is free and available on GitHub — self-hosting means you pay only for the server, not for n8n as software.

Before you start, decide on a domain or subdomain if you want to access your n8n instance over HTTPS rather than a bare IP address, since workflows that use webhooks generally need a stable, reachable URL. You'll also want a way to persist data across container restarts — a mounted volume for n8n's database and credentials — so a redeploy doesn't wipe your workflows. Have a plan for backups too, since none of this is handled for you automatically the way it would be on a managed Cloud plan.

Step-by-step

Start by provisioning your VPS and connecting over SSH, then install Docker and Docker Compose if they aren't already present. From there, the general flow is:

1. Create a working directory for your n8n deployment and a Docker Compose file that defines the n8n service, mapping a persistent volume for its data directory.
2. Set environment variables for your instance, including the timezone, a webhook URL if you're using one, and basic authentication or an owner account for the editor UI.
3. Bring the container up and confirm it's reachable on the port you've exposed, then complete the initial owner-account setup through the n8n editor in your browser.
4. If you want HTTPS on a real domain, put a reverse proxy in front of the container — this is the point where most self-hosting guides diverge based on which proxy you prefer, but the underlying n8n container doesn't change.
5. Once the instance is running, build and test a simple workflow to confirm executions run correctly and that any credentials you configure are saved and reused as expected.

Because billing inside n8n is per workflow execution rather than per step, you don't need to worry about workflow complexity driving cost while self-hosting — steps within a single run are unlimited regardless of hosting model. That matters less while self-hosted, since there's no execution-based bill at all, but it's worth understanding if you ever move some workloads to n8n Cloud later. For a hands-on next step once your instance is running, our n8n AI agent tutorial walks through building a workflow with AI agent nodes, which n8n handles natively.

Common problems

The most common issue is losing data on a redeploy because the container's data directory wasn't mounted to a persistent volume — if you rebuild or restart the container without that volume in place, your workflows, credentials, and execution history disappear. Double-check your Compose file mounts a host directory or named volume before you invest real time building workflows.

Webhook-triggered workflows are the second common source of trouble: if your VPS doesn't have a stable public URL or your reverse proxy isn't correctly forwarding requests, webhook nodes will fail silently or time out without an obvious error message. Test webhook-triggered workflows early, before you've built a large automation around one, so you catch connectivity issues while the workflow is still simple.

The third common problem is treating self-hosting as a one-time setup rather than an ongoing responsibility. Self-hosting means you own upgrades, backups, and uptime — n8n doesn't patch or back up your instance for you the way the Cloud tiers do. Skipping upgrades for months can leave you on a version with known issues, and skipping backups means a server failure can take your workflows with it.

A fourth issue worth naming is resource sizing. A minimal VPS is enough to get n8n running, but workflows with heavy AI agent nodes, large file processing steps, or many concurrent executions can push a small instance to its limits, showing up as slow executions or the container restarting under memory pressure. Monitor resource usage once you're running real workflows, not just during initial testing, and be ready to resize the VPS if usage grows past what the original sizing assumed, rather than waiting for executions to start failing before you notice.

What to do next

Once your self-hosted instance is stable, the next step is deciding which workflows are worth building and whether self-hosting remains the right call as your usage grows over time. If your automation needs stay modest, self-hosting keeps your only cost as the VPS bill, with no per-execution charge at all. If you eventually want managed infrastructure without the upgrade and backup responsibility, n8n's Cloud tiers are priced in euros — Starter at €20/mo for 2,500 executions, Pro at €50/mo for 10,000 executions, and Business at €667/mo for 40,000 executions, all billed annually — worth comparing against your VPS cost once your workflow volume grows.

If you're deciding between n8n and a SaaS-only automation tool before committing to any self-hosting effort at all, our n8n vs Zapier comparison covers that self-hosted-versus-SaaS trade-off directly, and our n8n vs Make comparison is worth a look if you're weighing two more technical-leaning tools against each other. Either way, the per-execution billing model — not per-step — carries through to n8n's paid tiers, so a workflow you build complex while self-hosting won't suddenly cost more if you migrate it to Cloud later on down the road.