n8n Self-Hosted: The Complete Deployment & Operations Guide
📘 n8n Knowledge Base Self‑Hosted · Production‑Ready Automation · Unlimited Executions
n8n Self‑Hosted: The Complete Deployment & Operations Guide
Docker | PostgreSQL vs SQLite | Queue Mode | Security | Monitoring | Cost | Updates | Reverse Proxy
n8n self‑hosted gives you unlimited workflow executions, full data ownership, and horizontal scaling. This guide covers production‑ready deployment using Docker, security hardening, queue mode with Redis + PostgreSQL, Prometheus monitoring, backup strategies, and direct cost comparisons. All facts are validated against official n8n documentation.

1. How do you deploy n8n self‑hosted in production using Docker?

📌 40‑word answer: Deploy n8n with Docker Compose using persistent volumes, PostgreSQL for database, and a reverse proxy (Nginx/Caddy). Set N8N_HOST and WEBHOOK_URL to your domain. Pin a specific version (e.g., n8nio/n8n:1.78.1) and mount a volume to preserve workflows and credentials.

The official n8n Docker image n8nio/n8n exposes port 5678 for the editor UI and REST API. For production, avoid SQLite and always mount a persistent volume to /home/node/.n8n. This folder contains SQLite (if used) and internal configuration. Docker Compose is the recommended orchestration tool.

version: '3.8'
services:
  n8n:
    image: n8nio/n8n:1.78.1
    environment:
      - N8N_HOST=automate.yourdomain.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://automate.yourdomain.com
      - N8N_ENCRYPTION_KEY=your-secure-key
    volumes:
      - n8n_data:/home/node/.n8n
    ports:
      - "5678:5678"
volumes:
  n8n_data:

Never use the :latest tag in production because automatic major upgrades can introduce breaking changes. Instead pin a specific version (e.g., 1.78.1) and test upgrades in a staging environment. For full deployment patterns including environment variables and health checks, refer to the dedicated n8n Docker Deployment Guide.

2. When should you use PostgreSQL instead of SQLite for n8n?

📌 40‑word answer: Use SQLite only for testing or less than 50 daily executions. For production workloads, concurrent access, or queue mode, migrate to PostgreSQL. SQLite does not support horizontal scaling and can cause data corruption under heavy write loads.

n8n defaults to SQLite, which stores all workflows and credentials in a single file (database.sqlite). While convenient for local testing, SQLite starts to degrade beyond ~50 executions per day. PostgreSQL provides better concurrency, transaction integrity, and is mandatory for queue mode (horizontal scaling).

⚠️ Critical: Queue mode does not work with SQLite. Enabling QUEUE_MODE_ENABLED=true with SQLite will cause execution failures. Always switch to PostgreSQL before scaling.

To migrate, export all workflows using the CLI (n8n export:workflow --all), reconfigure DB_TYPE=postgresdb with connection parameters, then re‑import workflows. Back up your original SQLite file first. Detailed instructions are available in the n8n database migration guide.

3. What is n8n queue mode and how does it horizontally scale?

📌 40‑word answer: Queue mode uses Redis as a message broker and PostgreSQL as database. The main process enqueues workflows; one or more worker containers consume jobs. This architecture allows unlimited horizontal scaling and parallel execution without single‑node bottlenecks.

In default mode, every workflow execution runs inside the main n8n process. Queue mode decouples the webhook/editor layer from execution. Workers pull jobs from a Redis queue and execute them independently. You can add as many workers as needed, each increasing total concurrency.

📈 Concurrency formula:
Total parallel workflows = number_of_workers × N8N_CONCURRENCY_PRODUCTION_LIMIT
Example: 3 workers × limit 5 = 15 simultaneous executions.

To enable queue mode, set QUEUE_MODE_ENABLED=true, QUEUE_BULL_REDIS_HOST to your Redis endpoint, and ensure PostgreSQL is used. The main instance and all workers must share the same N8N_ENCRYPTION_KEY. Learn advanced worker configuration and Redis tuning in the Queue Mode & Workers deep dive.

4. How does n8n encrypt credentials and why is N8N_ENCRYPTION_KEY critical?

📌 40‑word answer: n8n encrypts all credentials using AES‑256‑CBC with a key derived from N8N_ENCRYPTION_KEY. If you lose the key, encrypted credentials become irrecoverable. Set the same key across all containers (main + workers) and back it up securely.

n8n stores OAuth tokens, API keys, and database passwords encrypted at rest. The encryption algorithm is AES‑256‑CBC. The environment variable N8N_ENCRYPTION_KEY supplies the master key. If you do not set it, n8n auto‑generates a key and stores it in /home/node/.n8n/config — but that key is not shared across replicas, causing decryption failures.

🚨 Disaster recovery warning: Without the exact encryption key, even a full database backup is useless — credentials cannot be recovered. Store the key in a secrets manager (e.g., Bitwarden, HashiCorp Vault) and never commit it to version control.

For production clusters, always define N8N_ENCRYPTION_KEY explicitly. Use a strong, random 64‑character string. Key rotation is not natively supported; you would need to decrypt and re‑encrypt credentials manually. More security best practices are covered in the n8n Security Hardening guide.

5. How can you monitor n8n self‑hosted with Prometheus and Grafana?

📌 40‑word answer: Enable n8n’s built‑in Prometheus metrics endpoint (/metrics) with N8N_METRICS=true. Configure Prometheus to scrape the endpoint, then visualise execution counts, error rates, and queue length in Grafana. Use community dashboards for quick setup.

n8n uses the prom-client library. To expose metrics, set N8N_METRICS=true and optionally N8N_METRICS_INCLUDE_DEFAULT_METRICS=true. The default endpoint is http://n8n-host:5678/metrics. You can protect it with basic auth.

# Prometheus scrape config
scrape_configs:
  - job_name: 'n8n'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['n8n-main:5678']

Key metrics include n8n_workflow_execution_total, n8n_workflow_execution_failed_total, and n8n_queue_jobs_waiting. Import a community Grafana dashboard (search “n8n”) or build your own to monitor execution latency, worker load, and error rates. Full metric reference is available in the Monitoring & Backup deep dive.

6. How does self‑hosted n8n cost compare to n8n Cloud, Zapier, and Make?

📌 40‑word answer: Self‑hosted n8n costs $5–20/month for a VPS (unlimited executions). n8n Cloud Starter limits 2,500 executions/month at €20/month. Zapier’s Professional plan starts at $29.99/month + 20k tasks. Self‑hosting becomes cheaper beyond ~3,000 monthly executions.
PlatformMonthly cost (entry)Execution / task limitSelf‑host option
n8n Self‑hosted (VPS)$5–20 (DigitalOcean, Hetzner)Unlimited✅ Yes
n8n Cloud Starter€20 (~$22)2,500 executions❌ No
Zapier Professional$29.9920,000 tasks❌ No
Make Pro$16.0820,000 operations❌ No

Self‑hosted n8n provides unlimited executions but requires infrastructure management (updates, backups, security). For teams processing >10k workflows/day, queue mode is the only viable path. Detailed ROI analysis, including hidden costs like maintenance time, can be found in the Self‑Hosted ROI vs Cloud comparison.

7. What is the safe way to update self‑hosted n8n without losing data?

📌 40‑word answer: Use Docker Compose: change the image tag to a new version, run docker compose pull && docker compose up -d. Persistent volumes retain all data. Always test in staging, back up the database and encryption key, and avoid the :latest tag.

n8n releases a new stable version every two weeks. Before upgrading, read the official changelog for breaking changes. For Docker Compose deployments, the upgrade procedure is:

docker compose stop n8n
docker compose pull n8n
docker compose up -d

Because data lives in persistent volumes, no data loss occurs. For queue mode, upgrade workers first, then the main instance. Mixed version operation is temporary but supported. Version pinning (using specific tags like n8nio/n8n:1.78.1) prevents accidental upgrades. Learn CI/CD automation and rollback strategies in the Version & CI/CD guide.

8. Why does n8n self‑hosted require a reverse proxy for HTTPS in production?

📌 40‑word answer: n8n does not handle SSL/TLS natively. A reverse proxy (Nginx, Caddy, Traefik) terminates HTTPS, provides WebSocket support for the editor, and adds security headers. Without a proxy, all traffic is plain HTTP, exposing credentials to interception.

n8n’s internal web server only speaks HTTP. To enable encrypted connections, place a reverse proxy in front. The proxy listens on port 443 (TLS) and forwards requests to http://localhost:5678. It must support WebSocket upgrades for the editor UI to work correctly.

# Minimal Nginx location block for n8n
location / {
    proxy_pass http://n8n:5678;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

Use Let’s Encrypt (Certbot for Nginx or built‑in for Caddy) to obtain free SSL certificates. Set N8N_PROTOCOL=https and N8N_HOST to your domain so n8n generates correct webhook URLs. Full configuration examples (Nginx, Traefik, Apache) are provided in the official reverse proxy documentation.

⚠️ Disclaimer: This information is provided for educational and informational purposes only. Always refer to the official n8n documentation for production decisions. Self‑hosting requires responsible security management, including regular updates, encryption key backups, and access controls. The author is not affiliated with n8n GmbH.