Keeping Your Self-Hosted n8n Alive:
Webhooks, Memory, and Queue Mode

How Self-Hosted n8n Breaks in Production

A self-hosted n8n instance installed on a DigitalOcean Droplet or an AWS EC2 box from a getting-started guide will run fine for days or weeks. Then, as your automation footprint grows, it starts failing in a handful of very specific ways. Knowing these failure modes by name is the first step to fixing them.

All four of these failures are solvable. But they require different interventions at different layers of the stack. Starting from the inside out — environment configuration, then proxy settings, then architecture — is the correct order.

The Root Cause: One Event Loop Doing Everything

n8n is built on Node.js, which runs on a single-threaded event loop. In a default single-instance deployment, that one event loop handles everything simultaneously: responding to incoming webhooks, executing workflow steps, serving the editor UI, writing execution logs to the database, and processing the results of API calls as they return.

Most of the time this works well. Node.js is extremely efficient at I/O-bound work — waiting for HTTP responses from external APIs is the dominant activity in most n8n workflows, and the event loop handles concurrent waits gracefully. The problem arises when something CPU-intensive or memory-intensive enters the loop.

The same applies to large JSON serialisation and deserialisation. Parsing a 15MB API response into n8n's internal data format is a synchronous CPU operation. While it's running, the event loop is blocked. Add three workflows doing this in parallel and you have a completely frozen instance.

Understanding this constraint tells you what the fixes are: either prevent the event loop from being blocked (configuration and workflow design), or move the execution work off the main process entirely (queue mode).

First-Line Defence: Timeout and Concurrency Environment Variables

Before touching your architecture, there are several environment variables that every production n8n deployment should have explicitly configured. The defaults are designed for development environments — they are not safe for production.

# ── Execution timeouts ─────────────────────────────────────────────
# Maximum time (seconds) any single workflow execution is allowed to run.
# Default is -1 (unlimited). On a shared VPS, set this to prevent runaway
# executions from monopolising the event loop indefinitely.
EXECUTIONS_TIMEOUT=3600

# Hard ceiling. Users and admins cannot set a timeout higher than this.
# Set to match or slightly exceed your longest legitimate workflow.
EXECUTIONS_TIMEOUT_MAX=7200

# ── Concurrency ─────────────────────────────────────────────────────
# Maximum concurrent production executions on this instance.
# Default is unlimited. On a 2 vCPU / 4GB Droplet, 5–10 is a safe start.
# Increase only after confirming memory headroom per execution.
N8N_CONCURRENCY_PRODUCTION_LIMIT=10

# ── Webhook response timeout ─────────────────────────────────────────
# How long n8n waits (ms) for a "respond to webhook" node to complete
# before returning a timeout response to the caller. Default: 5000ms.
# Set to match your slowest legitimate synchronous webhook workflow.
N8N_DEFAULT_WEBHOOK_TIMEOUT=30000

# ── Payload limits ───────────────────────────────────────────────────
# Maximum inbound request body size (bytes). Default: 16MB.
# For most webhook integrations 16MB is already large; lower it to
# prevent deliberate or accidental oversized payloads from hitting memory.
N8N_PAYLOAD_SIZE_MAX=8388608

# ── Process hygiene ──────────────────────────────────────────────────
# Prune execution history to prevent the database from growing without bound.
# Keep the last 1000 executions per workflow; delete anything older than 30 days.
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=720
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none

A few of these deserve elaboration.

EXECUTIONS_TIMEOUT=3600 is a protection against the runaway workflow — one that gets into an unexpected loop, or calls an external API that never responds. Without a timeout, a single stuck execution can hold the event loop partially occupied indefinitely. Set this to the maximum time any of your workflows could legitimately need; 3600 seconds (one hour) is a conservative ceiling that catches most problems.

N8N_CONCURRENCY_PRODUCTION_LIMIT is the most impactful single variable for preventing memory spikes. By default, n8n will attempt to run as many concurrent executions as it receives. If 30 webhook calls arrive simultaneously, n8n attempts to start 30 executions. On a 4GB VPS where each execution consumes 200–400MB, that's an immediate OOM kill. Setting this to 10 means n8n queues incoming executions and processes them at a steady rate rather than attempting to parallelise infinitely.

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none is a significant quality-of-life change for busy instances. By default n8n saves the full data for every successful execution. On a high-volume instance processing thousands of executions daily, this grows your database by gigabytes per week and adds write overhead to every execution. Save on error only unless you have a specific debugging need for successful execution data.

Nginx Configuration for Long-Running Webhooks

The vast majority of n8n webhook timeout issues reported on forums and community threads are not n8n problems at all — they're proxy problems. Nginx's default proxy_read_timeout is 60 seconds. If your workflow takes longer than 60 seconds to produce a response (even a simple "received" response), Nginx closes the connection and returns a 504 to the caller. n8n never had a chance to respond.

There are two categories of n8n webhook workflows and they need different proxy handling.

For production instances handling both types, here is the Nginx server block configuration that covers both cases correctly:

server {
    listen 443 ssl http2;
    server_name n8n.yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/n8n.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.yourdomain.com/privkey.pem;

    # ── Standard proxy settings ─────────────────────────────────────
    client_max_body_size 16m;
    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # ── Timeouts for standard editor and API traffic ─────────────────
    proxy_read_timeout  120s;
    proxy_send_timeout  120s;
    proxy_connect_timeout 10s;

    location / {
        proxy_pass http://127.0.0.1:5678;

        # WebSocket support — required for the n8n editor's live UI
        proxy_http_version 1.1;
        proxy_set_header Upgrade    $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    # ── Elevated timeouts for synchronous webhook workflows ──────────
    # Apply only to /webhook/ paths. This does NOT affect the editor.
    # Match N8N_DEFAULT_WEBHOOK_TIMEOUT plus a 30s buffer.
    location /webhook/ {
        proxy_pass http://127.0.0.1:5678;
        proxy_read_timeout  300s;
        proxy_send_timeout  300s;
        proxy_http_version  1.1;
        proxy_set_header    Upgrade    $http_upgrade;
        proxy_set_header    Connection "upgrade";
    }

    # Test/manual webhook endpoints use the same elevated timeout
    location /webhook-test/ {
        proxy_pass http://127.0.0.1:5678;
        proxy_read_timeout  300s;
        proxy_send_timeout  300s;
        proxy_http_version  1.1;
        proxy_set_header    Upgrade    $http_upgrade;
        proxy_set_header    Connection "upgrade";
    }
}

The critical detail here is the path-scoped timeout on /webhook/. You do not want proxy_read_timeout 300s on the entire server block — that would allow broken clients to hold editor connections open for five minutes each, which is a different kind of resource exhaustion. Scope the elevated timeout to webhook paths only, and keep the editor on a shorter leash.

Memory Management: Stopping the OOM Killer

Memory is the most common cause of unexpected n8n process death on self-hosted instances. The Linux OOM (out-of-memory) killer terminates the largest memory consumer when the system runs out of RAM. On a 2GB Droplet running n8n, that's always n8n.

The memory profile of a running n8n instance looks like this: the base process consumes around 300–450MB at rest. Each active execution adds 50–200MB depending on data volume. A workflow that fetches a large paginated API response, or one that uses a Code node to build a large array, can spike to 800MB for a single execution. Three such executions running simultaneously on a 2GB VPS will kill the process.

NODE_OPTIONS=--max-old-space-size=1536

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

N8N_DEFAULT_BINARY_DATA_MODE=filesystem
N8N_BINARY_DATA_STORAGE_PATH=/home/n8n/.n8n/binaryData

Recognising the Signals That Tell You Queue Mode Is Needed

Environment variable tuning and proxy configuration will take a well-configured single-instance n8n surprisingly far. But there is a ceiling. When you hit it, the only real fix is queue mode — and the signals are unmistakable once you know what to look for.

If you're seeing two or more of these symptoms, adding more environment variables won't help. The architecture has to change.

Queue Mode Architecture: How It Works

Queue mode splits the single n8n process into three distinct roles. Each role runs as a separate container (or process), and each one can be scaled independently.

The architectural win is separation of concerns. Incoming webhooks now hit the main instance, which responds immediately by queueing the job — the caller gets an acknowledgement in milliseconds, not after the workflow finishes. Workers execute the actual workflow in parallel, as many as you've configured. A worker that crashes takes only its own current execution with it; the main instance and the other workers continue unaffected.

This also means you can schedule maintenance on workers independently. Drain a worker's queue (stop sending it new jobs), wait for its current execution to finish, update the container, restart it. Zero-downtime maintenance on the execution layer.

Queue Mode Setup on DigitalOcean / AWS (Docker Compose)

The following docker-compose.yml is a production-ready queue mode setup for a single Droplet or EC2 instance. It runs the main n8n instance, two workers, and Redis on the same host. For higher loads, workers can be moved to separate hosts — but starting with this collocated configuration lets you validate the setup before adding network complexity.

version: "3.8"

# Shared environment variables for all n8n containers.
# Store these in a .env file alongside docker-compose.yml — never hardcode.
x-n8n-env: &n8n-env
  DB_TYPE: postgresdb
  DB_POSTGRESDB_HOST: your-postgres-host
  DB_POSTGRESDB_PORT: 5432
  DB_POSTGRESDB_DATABASE: n8n
  DB_POSTGRESDB_USER: n8n_user
  DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}

  # Queue mode activation
  EXECUTIONS_MODE: queue
  QUEUE_BULL_REDIS_HOST: redis
  QUEUE_BULL_REDIS_PORT: 6379

  # CRITICAL: This key must be IDENTICAL across main and all workers.
  # Different keys mean workers cannot decrypt credentials — every workflow fails.
  N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}

  # Timeouts and limits (match Nginx proxy_read_timeout)
  EXECUTIONS_TIMEOUT: 3600
  EXECUTIONS_TIMEOUT_MAX: 7200
  N8N_DEFAULT_WEBHOOK_TIMEOUT: 30000
  N8N_CONCURRENCY_PRODUCTION_LIMIT: 10

  # Memory and payload
  NODE_OPTIONS: --max-old-space-size=1024
  N8N_PAYLOAD_SIZE_MAX: 8388608
  N8N_DEFAULT_BINARY_DATA_MODE: filesystem
  N8N_BINARY_DATA_STORAGE_PATH: /home/node/.n8n/binaryData

  # Execution data pruning
  EXECUTIONS_DATA_PRUNE: "true"
  EXECUTIONS_DATA_MAX_AGE: 720
  EXECUTIONS_DATA_SAVE_ON_ERROR: all
  EXECUTIONS_DATA_SAVE_ON_SUCCESS: none

  N8N_HOST: n8n.yourdomain.com
  N8N_PROTOCOL: https
  WEBHOOK_URL: https://n8n.yourdomain.com/

services:

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    volumes:
      - redis_data:/data
    command: redis-server --appendonly yes --maxmemory 256mb --maxmemory-policy allkeys-lru
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

  n8n-main:
    image: n8nio/n8n:latest
    restart: unless-stopped
    environment:
      <<: *n8n-env
    ports:
      - "127.0.0.1:5678:5678"
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      redis:
        condition: service_healthy
    command: ["n8n", "start"]

  n8n-worker-1:
    image: n8nio/n8n:latest
    restart: unless-stopped
    environment:
      <<: *n8n-env
      # Each worker runs up to 10 jobs concurrently.
      # I/O-heavy workflows: set 10–20. CPU-heavy: set 2–5.
      N8N_CONCURRENCY_PRODUCTION_LIMIT: 10
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      redis:
        condition: service_healthy
      n8n-main:
        condition: service_started
    command: ["n8n", "worker", "--concurrency=10"]

  n8n-worker-2:
    image: n8nio/n8n:latest
    restart: unless-stopped
    environment:
      <<: *n8n-env
      N8N_CONCURRENCY_PRODUCTION_LIMIT: 10
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      redis:
        condition: service_healthy
      n8n-main:
        condition: service_started
    command: ["n8n", "worker", "--concurrency=10"]

volumes:
  redis_data:
  n8n_data:

There are three things in this configuration that will silently destroy your deployment if you get them wrong:

Scaling Workers and Sizing Your Droplet or EC2 Instance

The question most teams get wrong when planning queue mode: they calculate the number of workers they need based on peak concurrent executions, without accounting for the memory each worker consumes.

Each n8n worker process consumes 200–500MB of RAM at steady state (not counting execution data spikes). The actual ceiling depends on how memory-intensive your workflows are. Before choosing hardware, profile your current single-instance setup:

# Watch n8n memory every 5 seconds while workflows run.
# Record the delta between peak and baseline to estimate per-execution cost.
watch -n 5 'ps aux | grep n8n | grep -v grep | awk "{print \$6/1024 \" MB\"}"'

# Or with Docker:
watch -n 5 'docker stats n8n-main --no-stream --format "{{.MemUsage}}"'

Use this sizing table as a starting point, then adjust based on your measured per-execution memory:

For CPU-heavy workflows (large Code nodes, image processing, complex data transformations), halve the concurrency-per-worker figures in this table and add workers instead. For I/O-heavy workflows (HTTP requests, database queries, API calls — the dominant pattern in most n8n deployments), the table values are appropriate.

On AWS, prefer memory-optimised instances (r-series) over compute-optimised (c-series) for n8n workers — most of the time is spent waiting, not computing. DigitalOcean's General Purpose Droplets are a cost-effective choice for the same reason; the dedicated vCPUs prevent noisy-neighbour CPU interference that affects latency on the Premium Intel/AMD lines.

Production Self-Hosting Checklist

Before declaring a self-hosted n8n instance production-ready, go through this list. Each item represents a failure mode we've seen take down a live instance.

Frequently Asked Questions