Why Your n8n VPS Keeps Crashing (And the Fix That Actually Works)

If your n8n instance keeps dying — the container restarts, workflows drop mid-run, or the whole box freezes — the cause is almost never the CPU. It's memory. n8n holds the entire workflow payload, intermediate transformations, and queued nodes in RAM while it waits on external APIs. A faster CPU doesn't shorten that wait; more RAM is what stops the crash.

The real cause: n8n is memory-bound, not CPU-bound

Most n8n execution time is spent waiting for HTTP responses from external APIs. During that wait the CPU sits idle while the workflow data stays parked in memory. When several workflows run at once, that parked data stacks up — and on a 1 GB box it doesn't take long to hit the ceiling. The process gets OOM-killed, the container restarts, and you see the crash loop.

This is why the RAM sizing guide puts n8n at 2 GB minimum for real automation, not the 512 MB that "it's just a small tool" suggests.

Fix 1: Give it enough RAM (the sizing table)

Start at 2 GB, watch real usage with htop for a week, and scale up only when swap starts getting hit. Most people never need more than 4 GB.

Fix 2: Turn on queue mode (the one that stops the crashes)

By default n8n runs in "main" mode — one process does everything, and a single heavy workflow can take the whole instance down. Queue mode splits the work: a main process handles the editor, and separate worker processes execute workflows. If one worker dies, the others keep running and the job gets retried.

# docker-compose.yml — n8n in queue mode with Postgres
services:
  n8n:
    image: n8nio/n8n
    environment:
      - EXECUTIONS_MODE=queue
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=change-me
      - N8N_HOST=automation.yourdomain.com
      - N8N_PROTOCOL=https
    command: start
  worker:
    image: n8nio/n8n
    environment:
      - EXECUTIONS_MODE=queue
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=change-me
    command: worker
  postgres:
    image: postgres:16
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=change-me
      - POSTGRES_DB=n8n
    volumes:
      - pg_data:/var/lib/postgresql/data
volumes:
  pg_data:

Queue mode needs a database (Postgres above) and more RAM for the workers — that's the 4 GB tier. It's the difference between "crashes weekly" and "runs for months."

Fix 3: Watch the real numbers, not the dashboard

Don't guess. Before you buy more RAM, measure what's actually happening:

# live memory pressure
htop
# container memory + restart count (the smoking gun)
docker stats --no-stream
docker inspect n8n --format '{{.RestartCount}} restarts'
# swap usage — if this climbs, you're out of RAM
free -h

If RestartCount is climbing and swap is filling, that's your confirmation: memory, not CPU. Add RAM or enable queue mode before touching anything else.

Fix 4: Don't expose n8n directly (security + stability)

Running n8n on a bare :5678 port with no TLS isn't just a security risk — it invites abuse that can crash the box. Front it with Caddy for automatic HTTPS and keep port 5678 internal. See the full n8n + Caddy setup for the production compose file.

The bottom line

n8n crashes on a VPS for one reason 90% of the time: not enough memory for the workflows you're running. Give it 2–4 GB, turn on queue mode if you're running real automation, and measure before you buy. That's the whole fix.

Compare cheap VPS prices →

Some links on this page are affiliate links. If you buy through them we may earn a commission at no extra cost to you.