n8n Self-Hosting Guide: How to Run Your Own Automation Server

One of the best things about n8n is that you can run it yourself. Unlike most automation platforms, it is open source and built to be self-hosted, which means your workflows and your data can live entirely on infrastructure you control. In this n8n self-hosting guide I will walk you through why you would do it, the realistic setup options, a Docker-based install you can actually follow, and the security and backup work that turns a hobby instance into something you can trust with a business. I will also be honest about when paying for managed cloud is the smarter move, because self-hosting is not free even when the software is.

I run self-hosted automation for clients regularly, so this is the workflow I actually use, not a theoretical one. If you are still deciding whether n8n is the right tool at all, start with my n8n for beginners guide and my honest take in n8n vs custom code.

Why self-host n8n in the first place

There are three reasons that come up again and again.

• Data privacy and control. When you self-host, the data flowing through your workflows never touches someone else's cloud. For anything sensitive (customer records, internal financials, regulated data) this is often the deciding factor.
• Cost at scale. Managed n8n cloud and tools like Zapier charge by execution or operation. A self-hosted instance on a small server runs unlimited executions for the flat cost of the box, which can be a fraction of the metered price once you fire thousands of workflows a day.
• Full feature access and freedom. You control the version, the environment variables, custom nodes, and integrations. Nothing is gated behind a higher plan.

If none of those apply to you, that is a useful answer too. It means managed cloud is probably fine and you can skip the operational burden entirely.

Your self-hosting options

Self-hosting is a spectrum, not a single choice. Here are the realistic options, roughly from easiest to most involved.

For almost everyone, Docker on a small VPS is the right answer. It is reproducible, easy to back up, and easy to move to a bigger server later. That is the path I will detail below.

Step one: provision a server

Pick a VPS provider you trust. Hetzner, DigitalOcean, Vultr, and Linode all work well. For a single-user n8n instance with moderate use, a small box with 2 GB of RAM is enough; bump to 4 GB if you run heavy workflows or large payloads. Create the server with a recent Ubuntu LTS, point a subdomain (for example n8n.yourdomain.com) at its IP address with an A record, and connect over SSH. Create a non-root user with sudo rather than living as root.

Step two: install Docker

Docker is what makes this maintainable. Install it with the official convenience script and add your user to the docker group:

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
# log out and back in so the group change applies

Modern Docker includes Compose, so you can describe the whole stack in one file and bring it up with a single command.

Step three: the docker-compose file

Here is a minimal but production-sensible setup: n8n backed by Postgres, with a persistent volume and the key environment variables. SQLite is the default, but I recommend Postgres the moment this is more than a toy, because it handles concurrent executions and larger histories far better.

services:
  n8n:
    image: n8nio/n8n:1.x
    restart: always
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - N8N_ENCRYPTION_KEY=your-long-random-secret
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - GENERIC_TIMEZONE=Asia/Jerusalem
    volumes:
      - n8n_data:/home/node/.n8n

The single most important value here is N8N_ENCRYPTION_KEY. n8n uses it to encrypt your stored credentials. If you lose it, every saved credential becomes unreadable. Generate a long random string, save it in a password manager, and never let it drift between deployments.

Step four: HTTPS is not optional

Do not expose n8n directly on plain HTTP. Put a reverse proxy in front of it that handles TLS automatically. Caddy is the easiest option; a two-line config fetches and renews a Let's Encrypt certificate for you. Nginx Proxy Manager is a friendly alternative with a web UI. Webhooks, OAuth callbacks, and the editor all assume HTTPS, so this step is part of getting a working instance, not a nice-to-have.

Step five: security and backups

This is the part hobby setups skip and regret. A self-hosted n8n instance is reachable from the internet and holds the keys to every service it connects to. Treat it accordingly:

• Firewall. Allow only ports 80, 443, and SSH. Close everything else.
• Authentication. Turn on n8n's user management or basic auth so the editor is not open to the world.
• Updates. Pin the image to a specific version. Read the changelog, test, then upgrade deliberately; do not run latest and let it surprise you.
• Backups. Schedule a nightly Postgres dump plus a copy of the data volume to off-server storage (S3, Backblaze, another box). A backup you have never restored is a hope, not a backup, so test a restore once.

None of this is exotic. It is the standard discipline of owning a server, which is the real cost of self-hosting that the word "free" hides.

When managed cloud is the better call

I self-host a lot, and I still tell plenty of people to pay for managed n8n cloud instead. Choose managed when:

• You do not want to be responsible for patching, monitoring, and backing up a server.
• Your volume is low enough that metered pricing is cheaper than a VPS plus your time maintaining it.
• You have no in-house comfort with Linux, Docker, or DNS, and no appetite to learn it.
• Downtime is expensive and you would rather someone else carry the on-call burden.

The honest math is this: self-hosting trades a recurring software bill for recurring operational work. If your time is worth more than the difference, managed wins. I dig into this same trade-off for the broader question of building versus buying in business automation for small business.

Putting it together

A solid self-hosted n8n setup is a small VPS, Docker Compose running n8n plus Postgres, a reverse proxy for HTTPS, a firewall, authentication, a saved encryption key, and automated off-server backups. Get those right and you have an automation server that is private, cheap to run at scale, and fully under your control. Skip the security and backup parts and you have a liability waiting to happen.

If you want a self-hosted n8n instance set up properly, hardened, backed up, and handed over so it just works, that is something I do for clients all the time. I can stand up the server, deploy your workflows, lock it down, and host it for you so you never think about the infrastructure again. Book a call and tell me what you want to automate, or reach out through my contact form and we will scope it together.