Hosting n8n on a VPS in 2026: Complete Self-Hosted Guide (Docker, HTTPS, Backups)

Workflow automation has evolved from a technical niche into an operational backbone for startups, digital agencies, and independent developers. In 2026, n8n remains the open-source reference, prioritizing flexibility and data sovereignty against proprietary SaaS giants.

Hosting n8n on your own VPS is no longer an option reserved solely for experienced DevOps engineers. Thanks to the maturity of Docker and modern reverse-proxy tools, deploying a robust, secure, and encrypted instance takes less than an hour. However, moving from the cloud to on-premise implies responsibilities: maintenance, backups, and monitoring.

This technical guide details the optimal architecture for 2026. We cover hardware sizing, installation via Docker Compose, TLS configuration, data persistence, and update strategies. The goal is to give you the keys to a reliable infrastructure without depending on quota limits or unpredictable price hikes from cloud platforms.

Sizing and VPS Selection: The Metrics That Matter

Before touching a single line of code, you must choose the infrastructure. n8n is a Node.js application, which means it is primarily CPU-bound when executing complex workflows and I/O-bound for database read/write operations.

Minimum vs. Recommended Specifications

Many outdated tutorials recommend 1 vCPU and 512 MB of RAM. In 2026, with heavier workflows involving image processing, local AI, or complex SQL queries, this configuration is risky for production.

Usage Profile	CPU	RAM	Storage	Estimated Monthly Cost (2026)
Lab / Tests	1 vCPU	1 GB	20 GB SSD	~€4
SMB / Light Usage	2 vCPU	2 GB	50 GB NVMe	~€10-15
Production / AI Integrations	2-4 vCPU	4 GB+	100 GB NVMe	~€25-40

Technical Analysis:

• RAM: n8n consumes approximately 150-300 MB at idle. Each active workflow in memory adds to the load. If you heavily use “Code” nodes (JavaScript/TypeScript) or host local LLM models via n8n, aim for a minimum of 4 GB.
• CPU: Parallel executions require dedicated cores. A VPS with “burst” cores (like AWS t3) can saturate during traffic spikes. Prioritize VPSs with dedicated cores or guaranteed CPU quotas for production.
• Storage: The SQLite database (default) works well for <100 workflows. For production, we will use PostgreSQL. Storage must be fast (NVMe) because execution logs and large payloads (images, PDFs) accumulate quickly.

Why a Dedicated VPS?

Hosting your solution requires a good VPS. “Shared” offers or shared containers on free PaaS platforms impose execution time and memory limits that break n8n workflow logic (which can take several minutes to process batch data). A VPS (from Hetzner, OVH, DigitalOcean, Vultr) gives you total control over the kernel, firewall, and resources, which is essential for long-term stability.

Architecture and Installation via Docker Compose

We will use Docker Compose to orchestrate two services: n8n and postgres. This separation is crucial for performance and backup capabilities.

Prerequisites

• SSH root or sudo user access on the VPS.
• Docker and Docker Compose installed (recent versions).
• A domain name pointing to the VPS IP (e.g., n8n.mydomain.com).

Step 1: Directory Structure

Let’s create a clean directory structure to facilitate maintenance.

mkdir -p ~/n8n/data/postgres
mkdir -p ~/n8n/data/n8n
cd ~/n8n

Step 2: The docker-compose.yml File

This file defines our containers. Note the use of environment variables for security and configuration.

version: '3.8'

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "5678:5678" # Internal port for debugging or direct reverse-proxy if needed
    environment:
      - N8N_HOST=n8n.mydomain.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - NODE_ENV=production
      - WEBHOOK_URL=https://n8n.mydomain.com/
      - GENERIC_TIMEZONE=Europe/Paris
      # Basic security
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=YourStrongPasswordHere
    volumes:
      - ./data/n8n:/home/node/.n8n
    depends_on:
      - postgres
    networks:
      - n8n-net

  postgres:
    image: postgres:15-alpine
    restart: always
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=AnotherEvenStrongerPassword
      - POSTGRES_DB=n8n
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    networks:
      - n8n-net

networks:
  n8n-net:
    driver: bridge

Technical Points to Note:

1. Volumes: n8n data (workflows, credentials) is stored in ./data/n8n. PostgreSQL data is in ./data/postgres. If you delete these folders, you lose everything.
2. Environment Variables: N8N_HOST and WEBHOOK_URL must match your public domain. N8N_PROTOCOL=https forces n8n to generate HTTPS links.
3. Basic Authentication: N8N_BASIC_AUTH is enabled here as an additional security layer, but in production, we will use a reverse-proxy that handles authentication or restricts access by IP.

Step 3: Startup

docker compose up -d

Check the logs to confirm there are no errors:

docker compose logs -f n8n

If you see n8n ready on port 5678, the service is functional. Access http://localhost:5678 via SSH tunneling or the public IP (not recommended without a proxy) to finalize the installation via the web wizard.

HTTPS Configuration and Reverse Proxy

Exposing n8n directly to the Internet is bad practice. You need a reverse-proxy to handle TLS encryption, request buffering, and security. In 2026, Caddy and Traefik are the leaders. Caddy is preferred here for its simplicity (auto-HTTPS via Let’s Encrypt) and minimalist configuration.

Installing Caddy

# On Debian/Ubuntu
sudo apt update
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Configuring Caddyfile

Edit /etc/caddy/Caddyfile. We will configure a reverse proxy that listens on port 80/443 and redirects to the n8n container.

n8n.mydomain.com {
    # Compression to optimize bandwidth
    encode gzip zstd

    # Proxy to the Docker container
    reverse_proxy localhost:5678 {
        # Important headers for security
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
        
        # Size limitation for heavy webhooks (images, files)
        # By default, Caddy might block payloads > 100MB
        request_body {
            max_size 200MB
        }
    }

    # Basic HTTP security (optional if you handle auth elsewhere)
    # basic_auth {
    #     admin $2a$14$... # bcrypt hash of the password
    # }
}

Security Note: Caddy automatically generates SSL/TLS certificates via Let’s Encrypt. Ensure port 80 (HTTP) is open in the VPS firewall for ACME validation, then all traffic will pass via HTTPS.

Restart Caddy:

sudo systemctl restart caddy
sudo systemctl enable caddy

Test your domain https://n8n.mydomain.com. You should see the n8n interface with the security padlock.

Security and Hardening

Having HTTPS is not enough. n8n often handles secrets (API keys, passwords). Here are the essential defense layers.

1. Secret Management

Never store API keys in plaintext within workflows. n8n includes an encrypted credential manager.

• Go to Settings > Credentials.
• Use system environment variables for critical secrets. n8n can inject process.env variables into “Code” nodes.
• In docker-compose.yml, you can define additional environment variables that will be accessible to workflows.

2. Firewall (UFW)

Close all ports except those necessary: SSH (22) and HTTP/HTTPS (80/443).

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full' # Or Caddy if detected, otherwise 80,443
sudo ufw allow 5678/tcp # Only if you need direct local access
sudo ufw enable

Tip: Disable direct access to port 5678 from the outside. The Caddy reverse-proxy should be the only entry point.

3. Securing n8n Access

• Strong Authentication: Enable two-factor authentication (2FA) in your n8n admin account settings.
• IP Limiting: If your workflow is sensitive, you can configure Caddy to allow only specific client IPs (company office, VPN).

  @allowed_ips remote_ip 192.168.1.0/24 10.0.0.0/8
  respond @allowed_ips "Access Allowed"

• Regular Updates: Security vulnerabilities are fixed in new versions. Configure automatic updates (see section below).

4. Log Monitoring

Enable detailed logging in n8n to detect intrusion attempts or workflow errors.

• In docker-compose.yml, add:

  environment:
    - N8N_LOG_LEVEL=debug # In production, switch to 'info' after stabilization

Backups: The 3-2-1 Rule

Automation is only useful if data is preserved. A manual backup is a failed backup. We will automate the backup of the PostgreSQL database and n8n configuration files.

Backup Script

Create a backup.sh script in the ~/n8n/ folder.

#!/bin/bash
DATE=$(date +%Y-%m-%d_%H-%M)
BACKUP_DIR="/mnt/backups/n8n" # Point to an external drive or another S3 server
N8N_DIR="$HOME/n8n/data/n8n"
PG_DIR="$HOME/n8n/data/postgres"

# Create date folder
mkdir -p "$BACKUP_DIR/$DATE"

# 1. PostgreSQL Backup (via docker exec to avoid installing pg_dump locally)
docker compose exec -T postgres pg_dumpall -U n8n > "$BACKUP_DIR/$DATE/n8n_db_dump.sql"

# 2. Archive n8n files (workflows, credentials)
tar -czf "$BACKUP_DIR/$DATE/n8n_files.tar.gz" -C "$HOME/n8n/data" n8n

# 3. Clean up backups older than 30 days
find "$BACKUP_DIR" -type d -mtime +30 -exec rm -rf {} \;

echo "Backup completed: $DATE"

Automation with Cron

Make the script executable and add it to the root or dedicated user’s crontab.

chmod +x ~/n8n/backup.sh
crontab -e

Add this line for a daily backup at 3 AM:

0 3 * * * /home/youruser/n8n/backup.sh >> /var/log/n8n-backup.log 2>&1

Pro Tip: For true resilience, send these archives to an external object storage (AWS S3, Backblaze B2, MinIO) after creation. You can add an aws s3 sync or rclone command at the end of the script.

Updates and Maintenance

n8n releases frequent updates. With self-hosting, you are responsible for compatibility.

Update Strategy

1. Do not update automatically without testing: Major version changes can break existing workflows.
2. Secure manual procedure:

   cd ~/n8n
   docker compose down
   docker compose pull # Fetches the latest image
   docker compose up -d

3. Verification: Check the n8n changelog before updating. Major versions (e.g., v1.0 to v2.0) often have breaking changes regarding workflow structure or nodes.

System Status Monitoring

Install a lightweight tool like uptime-kuma or prometheus + grafana to monitor:

• CPU/RAM usage of n8n.
• Number of successful/failed executions (via the n8n API).
• Available disk space.

An alert on disk usage is crucial: PostgreSQL logs and temporary files can fill the disk in a few days if a workflow runs in an error loop.

Cost Comparison: Self-Hosted vs. n8n Cloud

To make an informed decision, let’s compare real costs.

Criteria	Self-Hosted (VPS)	n8n Cloud (Starter)
Monthly Cost	~€10-15 (Basic VPS)	~€20-25 (Starting from ~2026 pricing)
Executions	Unlimited (limited by CPU/RAM)	Limited (e.g., 1000/month)
Max Execution Time	Depends on VPS (no strict hard limit)	Limited (e.g., 30 sec per workflow)
Maintenance	Your responsibility (Updates, Backups)	None (Managed)
Sovereignty	Total (data on your server)	With n8n (EU/US)
Scalability	Horizontal (adding workers)	Automatic but costly

Analysis: For personal use or a small business (<50 light workflows), the cloud might be more cost-effective in terms of time. However, as soon as you need long workflows (data processing, AI), massive parallel executions, or want to avoid per-execution fees, the VPS becomes immediately more profitable. Moreover, the VPS allows you to multiply instances (dev, staging, prod) for the price of one.

Which Choice for Your Profile?

The Maker / Solo Developer

Choice: Self-Hosted on 2 vCPU / 2 GB RAM VPS. You have the technical skills to manage Docker and backups. You want to control your data and avoid quotas. A VPS from Hetzner or OVH is perfect. Invest time in automating backups from day 1.

Agency / SME (Critical Usage)

Choice: Self-Hosted on High-Availability VPS + Monitoring. Automation is vital. You must host on a robust VPS (4 vCPU, 8 GB RAM) with a reverse-proxy configured for high availability. Plan for external backup (S3) and a disaster recovery plan. The initial cost is higher, but the ROI on unlimited executions is immediate.

Enterprise

Choice: Kubernetes or Managed Cloud. If you have a DevOps team, deploy n8n on Kubernetes for automatic horizontal scalability. Otherwise, use n8n Cloud Enterprise to benefit from SLA and dedicated support. Self-hosting on a simple VPS is not recommended for critical loads without infrastructure expertise.

FAQ

Can I host n8n on a NAS (Synology/QNAP)?

Yes, technically possible via Docker. However, NAS devices have I/O and CPU limitations that can slow down complex workflows. Additionally, managing updates and backups is more manual. For light usage (notifications, simple syncs), it is viable. For production, a VPS is more reliable.

How do I migrate from n8n Cloud to my VPS?

n8n provides an export/import tool.

1. On n8n Cloud, export your workflows (JSON).
2. Export your credentials (if possible, or re-enter them).
3. Import the JSON workflows into your self-hosted instance.
4. Recreate credentials in the local interface. Note: Webhook URLs will change; you will need to update external endpoints (Stripe, Slack, etc.) to point to your new domain.

What is the security risk of exposing n8n?

The main risk is not n8n itself, but the configuration. Exposing n8n without HTTPS, without strong authentication, or with plaintext secrets is dangerous. With a reverse-proxy (Caddy/Traefik), mandatory HTTPS, a restrictive firewall, and regular updates, the risk is comparable to any other well-maintained web service. The key is maintenance discipline.

Can I use n8n for local AI?

Yes. n8n supports LLM model integration. If you host a local model (via Ollama, for example) on the same VPS, you can call it from n8n. Ensure you have enough RAM (16 GB+) and a GPU if possible for a smooth experience. The Docker architecture facilitates deploying Ollama alongside n8n.

---

Disclaimer: This guide is provided for informational purposes. Infrastructure management carries risks. Always test your backups and restoration procedures in a staging environment before applying them in production.