Deployment GuideUpdated August 22, 2026

self-hosted automation

How to Install n8n on a VPS

Deploy n8n with Docker Compose, a persistent volume, HTTPS and webhook-friendly settings.

n8n is easy to start and surprisingly easy to forget about. A production setup needs more than a running container: persistent data, a stable public webhook URL, protected credentials, controlled updates and a backup you can restore. This guide uses Docker Compose on Ubuntu and keeps n8n's internal port private behind a reverse proxy.

Why this matters

Self-hosting n8n makes sense when automations need to run after your laptop closes, receive webhooks at a stable address or handle data you do not want passing through another hosted automation account. The trade-off is ownership: n8n Cloud removes most server work, while a VPS gives you control over region, retention and integrations but makes uptime, updates and recovery your job.

n8n Cloud or a VPS?

Choose n8n Cloud

You want the automation product but do not want to own Linux updates, reverse proxy configuration, monitoring or restores.

Choose a VPS

You need a fixed region, control of stored data, custom integrations or predictable server cost, and you will maintain it.

VPS requirements

Buy for the workload, not the install command

Find a matching VPS
Minimum1 vCPU / 2 GB RAM / 25 GB SSD

Personal testing, a few scheduled workflows and low webhook traffic. Expect little room for spikes.

Recommended2 vCPU / 4 GB RAM / 40+ GB NVMe

A small production instance with PostgreSQL, a reverse proxy and regular backups.

Heavy workload4+ vCPU / 8+ GB RAM / 80+ GB NVMe

Concurrent executions, queue mode, Redis, workers or workflows that process large files.

Compare VPS plansBrowse current deals
The part that breaks most often

n8n is not just a container. The public HTTPS URL, encryption key, persistent data and backup restore path all need to agree.

The production shape

InternetHTTPSCaddy / Nginx127.0.0.1:5678n8n + PostgreSQLencrypted backupOff-server storage

Before touching the server

  • Ubuntu 22.04 or 24.04 VPS with root or sudo access
  • A domain or subdomain already pointed at the VPS
  • At least 2 vCPU and 4 GB RAM for a small production workflow set
  • Docker Engine and the Docker Compose plugin

Build it in five deliberate moves

01

Create an isolated project directory

Keep the Compose file and environment file together, but do not commit the environment file to a public repository.

sudo mkdir -p /opt/n8n
sudo chown -R $USER:$USER /opt/n8n
cd /opt/n8n
02

Create the environment file

Replace the hostname with your real subdomain. The encryption key must stay unchanged for the life of the installation because n8n uses it to protect saved credentials.

cat > .env <<'EOF'
N8N_HOST=n8n.example.com
N8N_PROTOCOL=https
N8N_PORT=5678
WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1
N8N_ENCRYPTION_KEY=replace-with-a-long-random-secret
GENERIC_TIMEZONE=UTC
EOF
chmod 600 .env
03

Start n8n with persistent storage

The named volume keeps workflows, users and credentials when the container is recreated. Put a reverse proxy such as Caddy or Traefik in front and publish only 80/443 publicly.

cat > compose.yml <<'EOF'
services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    env_file: .env
    ports:
      - 127.0.0.1:5678:5678
    volumes:
      - n8n_data:/home/node/.n8n
volumes:
  n8n_data:
EOF
docker compose up -d
docker compose logs -f n8n
04

Finish HTTPS and test a webhook

In the reverse proxy, forward the host to 127.0.0.1:5678 and preserve X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto. Then create a test webhook and call it from a second network.

05

Back up before the first real workflow

Back up the n8n volume and any external database used by your workflows. Export a small workflow, delete it in a test project, and confirm that you can restore it before relying on the server.

Common mistakes that cause real downtime

  • Sizing only for idle memory and ignoring concurrent executions or large binary files
  • Changing N8N_ENCRYPTION_KEY after credentials have already been saved
  • Exposing port 5678 directly instead of putting HTTPS and access controls in front
  • Backing up the Compose file but not the database, n8n data volume and encryption key
  • Using the latest image tag in production without a tested update and rollback routine

The first workflow should be a recovery test

Before you connect a business webhook, export a small workflow, back up the n8n data and database, delete a test item and restore it. The goal is to prove that credentials, workflows and the public webhook URL survive normal operations.

Before production

docker compose ps shows the n8n service as running
The editor opens at the HTTPS hostname without a certificate warning
A test webhook reports the public HTTPS URL rather than http://127.0.0.1:5678
The n8n data volume is included in a backup job

Next step

Keep the deployment moving

Sources and further reading

Commands assume a fresh Ubuntu server. Replace domains, users, database names and provider-specific values before running them. VPS sizing is a practical starting point, not a guarantee: monitor the real workload and resize when CPU, memory, disk or network headroom becomes tight.