How to Self-Host n8n on a VPS in 2026: A Production Setup Guide

n8n has become the default choice for teams that want Zapier-style automation without per-task pricing or sending every customer record through a third-party cloud. Running it yourself is easy. Running it so it survives restarts, upgrades and a busy Monday morning takes a little more planning. This guide walks through a production-ready n8n setup on a VPS: what size server you need, how to deploy it with Docker Compose and PostgreSQL, how to put it behind HTTPS, and what to back up so you never lose a workflow.

Why self-host n8n instead of using a hosted plan?

• Predictable cost. You pay for the server, not for each execution. Heavy workflows that poll APIs every minute stop being a billing problem.

• Data control. Credentials, webhook payloads and execution logs stay on infrastructure you choose, in the country you choose.

• No artificial limits. Custom nodes, community nodes, long-running executions and private network access to your own databases are all on the table.

The trade-off is that you own updates, backups and uptime. The rest of this guide is about making that part boring.

What server size does n8n actually need?

n8n itself is a Node.js application and is light at idle. What drives resource use is how many executions run at the same time and how much data each one holds in memory. As a rule of thumb:

• Personal or small team, under a few thousand executions a day: 2 vCPU and 4 GB RAM is comfortable.

• Business workloads with large JSON payloads, file processing or AI nodes: start at 4 vCPU and 8 GB RAM.

• Queue mode with separate workers: size each worker for your heaviest workflow, and add workers rather than making one machine bigger.

Fast NVMe storage matters more than people expect, because every execution is written to the database. A Linux VPS with NVMe and full root access is a good fit for most teams; if you want resources that are never shared with other tenants, a Cloud VPS with dedicated vCPU and RAM removes noisy-neighbour slowdowns from the equation.

Step 1: Prepare the server

Start from a clean Ubuntu 24.04 or Debian 12 image. Create a non-root user, enable SSH keys, and install Docker Engine with the Compose plugin from Docker's official repository. Point a subdomain such as automation.yourcompany.com to the server's IP address before you continue, because the HTTPS certificate depends on it.

Step 2: Use PostgreSQL, not the default SQLite

n8n ships with SQLite so you can try it in minutes. For production, switch to PostgreSQL: it handles concurrent executions better, is easier to back up consistently, and is required if you later move to queue mode. A minimal docker-compose.yml looks like this:

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

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    depends_on: [postgres]
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-me
      N8N_HOST: automation.yourcompany.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://automation.yourcompany.com/
      N8N_ENCRYPTION_KEY: generate-a-long-random-string
      GENERIC_TIMEZONE: Africa/Cairo
      EXECUTIONS_DATA_PRUNE: "true"
      EXECUTIONS_DATA_MAX_AGE: "336"
    ports:
      - "127.0.0.1:5678:5678"
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  pg_data:
  n8n_data:

Two settings deserve attention. N8N_ENCRYPTION_KEY encrypts every credential you store; if you lose it, saved credentials cannot be decrypted, so keep a copy in your password manager. EXECUTIONS_DATA_PRUNE with a maximum age (in hours) stops the execution history from slowly filling your disk.

Step 3: Put n8n behind HTTPS

Notice that port 5678 is bound to 127.0.0.1 only. n8n should never be exposed directly to the internet. Put a reverse proxy in front of it, Caddy being the simplest option because it requests and renews Let's Encrypt certificates automatically:

automation.yourcompany.com {
    reverse_proxy 127.0.0.1:5678
}

Nginx or Traefik work just as well if you already use them. Whatever you choose, make sure WebSocket connections are proxied, otherwise the editor will feel broken.

Step 4: Back up the three things that matter

1. The PostgreSQL database, which holds workflows, credentials and execution history. Schedule a nightly pg_dump and copy it off the server.

2. The encryption key, stored somewhere other than the server itself.

3. Workflow exports, ideally committed to a private Git repository, so you can see what changed and roll back a single workflow without restoring the whole database.

Test a restore at least once. A backup you have never restored is a hope, not a plan.

Step 5: Scale with queue mode when you need it

When one instance can no longer keep up, n8n's queue mode splits the work: the main instance receives triggers and webhooks, Redis holds the queue, and one or more worker containers run the executions. You enable it with EXECUTIONS_MODE=queue and point every instance to the same Redis and PostgreSQL. Workers can live on the same VPS at first and move to separate servers later without changing your workflows.

Day-two checklist

• Pin the n8n image to a specific version and upgrade deliberately after reading the release notes.

• Enable two-factor authentication for every n8n user.

• Monitor disk usage and container restarts, not just whether the server responds to ping.

• Keep webhook URLs out of public repositories; treat them like passwords.

Where to run it

Pick a data center close to the services your workflows talk to most. IM HOST runs Linux VPS and Cloud VPS in the United States, the United Kingdom, Poland, Germany and Egypt, with full root access, NVMe storage and 24/7 support from engineers, so you can place n8n next to your data instead of the other way around. Compare plans on our Linux VPS and Cloud VPS pages, or check our data center locations.