How to Self-Host n8n on a VPS in 2026

n8n has become one of the most popular self-hosted automation platforms for people who want more control than hosted tools such as Zapier or Make. It can run scheduled workflows, receive webhooks, call APIs, move data between apps, trigger AI agents, process forms, update CRMs and glue together internal systems without paying per automation run.

That popularity also means more people are searching for how to run n8n properly on a VPS. The basic install is easy. The harder part is running it in a way that survives updates, keeps credentials safe, handles real workflow load and does not turn into a public security problem.

This guide walks through a practical n8n VPS setup for 2026, from sizing and Docker Compose through PostgreSQL, Redis, backups, security and how to run it cleanly on HYEHOST.

Why self-host n8n instead of using n8n Cloud?

n8n Cloud is convenient, but self-hosting gives you control over the runtime, data location, execution volume and network environment.

Self-hosting makes sense when you want:

• Your workflow credentials and execution data to stay on your own server.
• More predictable monthly infrastructure cost.
• Private access to internal services, databases or APIs.
• Custom community nodes or custom code.
• Higher workflow volume without per-execution pricing.
• A place to combine automation with AI agents, webhooks and private tools.

It is not always the easiest path. You are responsible for updates, backups, TLS, access control and monitoring. If you are comfortable with Linux, Docker and basic security, a VPS is a strong base.

Minimum n8n VPS requirements

For a tiny personal setup, n8n can start small. For production use, plan more carefully.

The biggest sizing mistake is thinking only about the n8n editor. The editor may load fine on a small VPS, but workflows can spike CPU, memory and disk usage when they process files, call AI APIs, loop through records or store large execution logs.

The clean production architecture

A sensible n8n deployment usually has these parts:

• n8n main container for the editor, API, scheduler and webhook handling.
• PostgreSQL for durable workflow and credential metadata.
• Redis if using queue mode and worker containers.
• n8n worker containers for heavier execution workloads.
• Reverse proxy such as Caddy, Nginx or Traefik for HTTPS.
• Backups for PostgreSQL and the n8n data directory.
• Firewall rules so only required ports are exposed.

SQLite is fine for testing, but PostgreSQL is the better default for a serious VPS install. If the workflows matter, use PostgreSQL from day one.

Basic Docker Compose example

This is a simplified starting point. Adjust domain names, passwords and paths before using it.

services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change-this-password
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: redis-server --appendonly yes
    volumes:
      - redis_data:/data

  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      - postgres
      - redis
    environment:
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-this-password
      QUEUE_BULL_REDIS_HOST: redis
      EXECUTIONS_MODE: queue
      N8N_ENCRYPTION_KEY: replace-with-a-long-random-secret
    volumes:
      - n8n_data:/home/node/.n8n
    ports:
      - "127.0.0.1:5678:5678"

  worker:
    image: n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      - postgres
      - redis
    command: worker
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-this-password
      QUEUE_BULL_REDIS_HOST: redis
      EXECUTIONS_MODE: queue
      N8N_ENCRYPTION_KEY: replace-with-a-long-random-secret
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  postgres_data:
  redis_data:
  n8n_data:

The important parts are PostgreSQL, Redis queue mode, a fixed encryption key and binding the n8n port to localhost. Your reverse proxy should be the public entry point, not the n8n container directly.

Reverse proxy and HTTPS

Do not expose n8n over plain HTTP. Use a reverse proxy with automatic TLS.

With Caddy, a simple public entry might look like:

n8n.example.com {
  reverse_proxy 127.0.0.1:5678
}

You can also place n8n behind Cloudflare, a VPN, Tailscale or an IP allowlist if it is only for internal use.

If your workflows need public webhooks, keep webhook paths public but lock down the editor as much as possible. Many n8n setups are compromised because the admin interface is exposed with weak credentials, old versions or poor access control.

Security checklist for n8n on a VPS

Because n8n can store credentials and execute workflows, treat it like a sensitive admin system.

• Use strong unique passwords and two-factor authentication where available.
• Keep n8n updated.
• Use a long fixed N8N_ENCRYPTION_KEY and back it up securely.
• Do not publish the editor on a random open port.
• Put the editor behind HTTPS.
• Restrict admin access by VPN or IP allowlist if possible.
• Avoid giving untrusted users workflow editing permissions.
• Be careful with Code nodes and community nodes.
• Back up PostgreSQL and the n8n data volume.
• Monitor CPU, memory, disk and failed login activity.
• Keep the host OS updated.

Backups that actually help

For n8n, a useful backup plan must include PostgreSQL database dumps, the n8n data directory or Docker volume, the Docker Compose file, the .env file or secret store, the encryption key and reverse proxy configuration.

Without the encryption key, restored credentials may be unusable. Without the database, workflows and execution history may be gone. Without the Compose file and environment values, the rebuild becomes guesswork.

A practical starting point is a daily PostgreSQL dump plus filesystem backups of the config and n8n volume. Test restoration on a separate VPS before assuming the backup is good.

When to use queue mode

Queue mode is useful when workflows can run for a while, spike memory or handle multiple events at once. It separates the web and editor process from execution workers.

Use queue mode when you have many scheduled workflows, webhooks arrive in bursts, AI workflows take longer to complete, you want to add more workers later or you do not want one heavy execution to affect the editor.

For a small personal setup, one main n8n container may be enough. For anything business-critical, queue mode with Redis is a better long-term base.

n8n and AI agents

n8n is increasingly used as the orchestration layer around AI agents. A workflow may receive a webhook, call an LLM, fetch data from an API, update a ticket, write to a database, send a Discord message or trigger another service.

For AI-heavy workflows, watch timeout settings, API rate limits, execution history growth, memory usage during large prompts or file handling, secrets stored in credentials and logs that may contain sensitive user data.

If you are running AI automation for clients, separate environments are usually worth it. One VPS for experiments and one VPS for production is cleaner than mixing everything together.

Where HYEHOST fits

HYEHOST is a practical fit for self-hosted n8n because the panel already gives customers the controls they need around a VPS.

• Deploy and manage VPS services from the panel.
• Choose Linux templates such as Debian or Ubuntu.
• Use console access if a firewall or network change breaks SSH.
• Monitor CPU, memory, disk and network usage.
• Add storage or bandwidth where available.
• Use private LANs for internal services.
• Add backups and recovery planning around the VPS.
• Open support tickets from the same panel when something needs review.

For a small n8n install, start with Cloud VPS. If workflows become heavier, move to a larger VPS, VDS, VPS Resource Pool or dedicated server depending on whether you need flexible scaling or dedicated hardware.

Suggested HYEHOST starting plans

For personal n8n automation, a small Cloud VPS is enough to get started. For business workflows, choose at least 4 GB RAM so PostgreSQL, Redis and n8n have breathing room.

• Learning and light personal automation: small Cloud VPS.
• Reliable personal or small team automation: 2-4 vCPU with 4 GB RAM.
• AI workflows and queue mode: 4+ vCPU with 8 GB RAM.
• Multiple customer stacks: VPS Resource Pools.
• High-volume or isolated automation: VDS or dedicated server.

You can start small, but do not undersize if n8n is handling production webhooks or business-critical workflows.

Common mistakes to avoid

• Running n8n on SQLite for a production workload.
• Forgetting to set and save N8N_ENCRYPTION_KEY.
• Exposing port 5678 directly to the internet.
• Leaving execution history unlimited.
• Running old n8n images for months.
• Not backing up PostgreSQL.
• Installing random community nodes without review.
• Mixing test workflows and production workflows on the same instance.
• Giving too many users workflow editing access.

Most n8n problems are not caused by n8n itself. They come from treating automation infrastructure like a throwaway test container after it becomes important.

n8n VPS FAQ

Can you self-host n8n on a VPS?

Yes. A VPS can run n8n with Docker, PostgreSQL, Redis queue mode, HTTPS and backups, giving you control over workflow data, credentials, execution volume and network access.

What VPS specs does n8n need?

A light n8n setup can start with 2 vCPU, 2 GB RAM and 30-50 GB SSD. Business workflows, AI calls or queue mode should usually start around 2-4 vCPU, 4 GB RAM and 50-100 GB SSD, with heavier installs moving to 4+ vCPU and 8+ GB RAM.

Should n8n use SQLite or PostgreSQL on a VPS?

SQLite is acceptable for testing, but PostgreSQL is the better default for a serious VPS install because workflow data, credentials and execution history matter once automations become production systems.

Final thoughts

n8n is one of the best reasons to run a VPS in 2026. It gives you private automation, flexible integrations, AI workflow orchestration and control over your data without being locked into per-execution pricing.

The right setup is not complicated: use Docker, PostgreSQL, Redis if you need queue mode, HTTPS, backups and sensible access control. Keep it updated, monitor it and size the VPS around the workflows you actually run.

If you want a simple start, deploy a HYEHOST VPS, point a domain at it, run n8n behind a reverse proxy and build from there. As your automation grows, the HYEHOST panel gives you room to add resources, private networking, storage and more advanced infrastructure without moving away from the same account and workflow.