How to Self-Host n8n (2026 Guide)

Self-hosting n8n gives you the full workflow-automation platform with no execution limits and complete ownership of your data. This guide walks through the real Docker, Docker Compose, and PostgreSQL setup honestly — and then shows the 30-second shortcut if you would rather skip the server administration entirely.

What does “self-hosting n8n” mean?

n8n is a source-available workflow automation tool. Unlike n8n Cloud — the hosted SaaS run by the n8n team — self-hosting means you run the n8n application on infrastructure you control. The software itself is free under a fair-code license, but the compute, database, storage, and bandwidth to keep it running 24/7 are not. Self-hosting is the right choice when you want no execution limits, full control over credentials and data, unlimited workflows, and the ability to use community nodes and custom code without a SaaS tier gating them.

n8n system requirements

n8n is lightweight to start but scales with how heavy your workflows are. A realistic baseline:

• CPU: 1 vCPU is fine for light use; 2+ vCPU for many concurrent executions.
• RAM: 1–2GB for n8n. Workflows that process large payloads (files, images, big JSON) need more.
• Database: PostgreSQL is strongly recommended for production. The default SQLite works for testing but does not handle concurrency well and is harder to back up safely.
• Storage: A few GB is enough to start; execution history and binary data grow over time.
• Network: A public HTTPS endpoint (port 443) so inbound webhooks and OAuth callbacks work.

For a deeper breakdown mapped to plan sizes, see our n8n vs n8n Cloud comparison.

Option 1: Deploy n8n with Docker

The quickest way to run n8n on your own machine or VPS is the official Docker image. This is great for a local trial, but note it uses SQLite and has no TLS — not what you want in production:

docker volume create n8n_data

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Open http://localhost:5678, create the owner account, and you have a working n8n. For anything real, move to Docker Compose with PostgreSQL.

Option 2: Docker Compose with PostgreSQL

A production setup pairs n8n with a dedicated PostgreSQL database, an encryption key, and the correct host and webhook URLs. Save this as docker-compose.yml:

services:
  postgres:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: n8n
    volumes:
      - pgdata:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-me
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
      N8N_ENCRYPTION_KEY: a-long-random-string
    depends_on:
      - postgres
    volumes:
      - n8ndata:/home/node/.n8n

volumes:
  pgdata:
  n8ndata:

Then run docker compose up -d. A few things that matter: set a strong N8N_ENCRYPTION_KEY (it encrypts your stored credentials — losing it means re-entering every credential), point WEBHOOK_URL at your real public HTTPS domain, and never expose port 5678 directly to the internet without a reverse proxy in front of it.

The parts self-hosting tutorials skip

Getting n8n running is the easy 20%. Keeping it running securely is the other 80%, and it is where a raw VPS bites you:

• TLS certificates: You need HTTPS for webhooks and OAuth. That means Caddy, Traefik, or Nginx plus Let’s Encrypt, and certificate renewal that must not fail.
• Webhooks & reverse proxy: Inbound webhooks require a stable public URL and correct proxy headers, or triggers silently break.
• Backups: Your workflows, credentials, and execution history live in PostgreSQL. You need automated, tested database backups — an untested backup is not a backup.
• Updates: n8n ships frequently. You are responsible for pulling new images, reading breaking-change notes, and migrating the database.
• Uptime: A single VPS is a single point of failure. If the host reboots at 2am, your scheduled workflows and webhooks stop until you notice.

Frequently asked questions