n8n Self-Hosting: Complete Docker Setup Guide

n8n self-hosting Docker Running n8n on your own infrastructure delivers data sovereignty, unlimited workflows, and predictable costs. Docker Compose lets you stand up an isolated, reproducible environment in minutes.

What Is n8n Self-Hosting and Why Choose It?

n8n self-hosting means running the workflow engine on your own server or cloud VM. Your data never passes through third-party servers; there are no monthly execution limits and licensing costs are fixed.

Data sovereignty is a hard requirement in enterprise environments. Regulatory frameworks in finance, healthcare, and the public sector mandate that customer data be processed on domestic or private infrastructure. When using n8n Cloud, all workflow data transits n8n GmbH servers. The self-hosting model eliminates this risk entirely: data is processed only in systems under your control.

The cost picture looks different too. When you review the n8n Cloud vs. self-hosted pricing comparison, it becomes clear that the Cloud plan's monthly fee scales rapidly as workflow count and execution volume grow. On your own server you pay only infrastructure costs; n8n Community Edition is completely free and open source. You can learn more about n8n's enterprise workflow automation capabilities to understand what you gain with the self-hosted stack.

The reason Docker enters the picture is straightforward: it provides a clean, isolated runtime, prevents dependency conflicts, and lets you version the entire stack in a single compose file. n8n officially recommends Docker-based deployment, and the official image on Docker Hub is continuously updated.

System Requirements

For small-to-medium enterprise use, 2 vCPU, 4 GB RAM, and 40 GB SSD are sufficient. Heavy workloads or high concurrency call for doubling these figures.

The table below shows recommended minimum and production hardware requirements for different usage scenarios. Values are derived from n8n official documentation and field experience; actual requirements vary by workload.

Ubuntu 22.04 LTS or Debian 12 is recommended as the operating system. Docker Engine 24+ and Docker Compose v2.x must be installed. Consider UFW for firewall management and either Certbot or Caddy for SSL certificate handling. Ensure your domain's A record points to the server; a valid A record is required for HTTPS provisioning.

Setting Up with Docker Compose

Define n8n, PostgreSQL, Nginx, and optional Redis in a single docker-compose.yml file to create a versioned, reproducible infrastructure. All environment variables are managed in a .env file.

Create your project directory and prepare the following structure. Use a .env file for passwords and sensitive values; never commit this file to a Git repository.

1. mkdir -p ~/n8n-stack && cd ~/n8n-stack — create the project directory.
2. Add N8N_ENCRYPTION_KEY, POSTGRES_PASSWORD, and N8N_HOST to the .env file.
3. Create docker-compose.yml: define the n8n service (image: n8nio/n8n), postgres service, nginx service (reverse proxy), and optional redis service.
4. Use named volumes for persistent data: n8n_data, postgres_data.
5. Start the stack in the background with docker compose up -d.
6. Monitor startup with docker compose logs -f n8n and complete the initial setup wizard.

Critical environment variables for the n8n service in docker-compose.yml: DB_TYPE=postgresdb, DB_POSTGRESDB_HOST=postgres, N8N_ENCRYPTION_KEY (random 32+ characters), WEBHOOK_URL (full domain), and N8N_BASIC_AUTH_ACTIVE=false (when using built-in auth). For the PostgreSQL service, set POSTGRES_DB, POSTGRES_USER, and POSTGRES_PASSWORD. All services should communicate over the same custom Docker network so containers resolve each other by service name without exposing internal ports.

Once the setup is complete, navigate to https://n8n.yourcompany.com in your browser. The first-run wizard will prompt you to create an administrator account. Immediately after account creation, enable Two-Factor Authentication from the Settings menu.

Database: SQLite vs. PostgreSQL

SQLite is appropriate only for single-user test environments. Production deployments must use PostgreSQL: data persists across restarts, backup tooling is mature, and queue mode requires PostgreSQL.

n8n defaults to SQLite. While this looks appealing for quick setup, SQLite can produce write-lock contention under concurrent access and slows down with large execution histories. Incorrect volume binding can also cause data loss when the Docker container restarts.

To migrate to PostgreSQL, export your workflows as JSON from Settings > Export in your current n8n instance, then import them into the new PostgreSQL-backed instance. Execution history cannot be migrated; only workflow definitions are transferred. This is why choosing PostgreSQL from the start is the right approach.

Reverse Proxy, HTTPS, and Domain Configuration

To expose n8n to the internet, configure a reverse proxy with Nginx or Caddy and obtain a valid SSL certificate. Caddy handles certificate management automatically; Nginx is more widely used and flexible.

The core Nginx reverse proxy configuration: listen on port 5678 of the n8n container as upstream, redirect HTTP port 80 traffic to 443, define SSL certificate paths on port 443, and add proxy_http_version 1.1, Upgrade, and Connection headers for WebSocket support. WebSocket support is mandatory for n8n's real-time workflow editor.

When Caddy is preferred, configuration simplifies dramatically. Just write your domain and backend address in the Caddyfile; Caddy automatically obtains and renews the SSL certificate from Let's Encrypt. Caddy v2 also supports dynamic configuration via its JSON API.

• Nginx: obtain the Let's Encrypt certificate with certbot --nginx -d n8n.yourcompany.com and set up a cron job for automatic renewal.
• Caddy: enable the reverse proxy with the reverse_proxy n8n:5678 directive; certificate management is automatic.
• In both cases, set n8n's WEBHOOK_URL environment variable to the full HTTPS address.
• Nginx buffer setting: proxy_read_timeout 300s; increase the timeout value for long-running workflow executions.

Queue Mode and Horizontal Scaling

n8n queue mode distributes workflow executions across multiple worker processes via Redis queues. The main n8n instance handles webhooks and the UI while workers process executions in the background.

In the default setup, all jobs run sequentially in a single n8n process. When concurrent workflow count increases or long-running jobs block other executions, queue mode should be activated. Compared to Zapier and Make, the flexibility n8n provides through queue mode is one of its standout differentiators.

To enable queue mode, add a Redis service to docker-compose.yml and set the following environment variables on the n8n service: EXECUTIONS_MODE=queue, QUEUE_BULL_REDIS_HOST=redis, and QUEUE_BULL_REDIS_PORT=6379. Then define a separate worker service: use the same n8n image but set the command to n8n worker --concurrency=5. The worker service must share the same volumes and network as the main n8n service.

• Scale workers dynamically with docker compose up -d --scale n8n-worker=3.
• Tune each worker's --concurrency value based on the server's CPU count.
• Set Redis maxmemory-policy to noeviction; queue data must not be evicted.
• Use Bull Dashboard or n8n's built-in execution queue view for monitoring.

Security, Backup, and Updates

A production n8n deployment requires UFW firewall, SSH key authentication, fail2ban, built-in 2FA, and an encrypted N8N_ENCRYPTION_KEY. Use PostgreSQL pg_dump and n8n data directory automation for backups.

A comprehensive guide is available on n8n security and enterprise governance. Key security steps: enable UFW and allow only ports 22 (SSH, non-default port), 80 (HTTP), and 443 (HTTPS). Restrict SSH to key-based authentication and disable password login. Install fail2ban to guard against brute-force attacks.

n8n-specific security: set the N8N_ENCRYPTION_KEY environment variable to a random, strong value; if this key is lost, encrypted credentials cannot be recovered. Enable n8n's built-in 2FA immediately after first login. Rely on n8n's own user management system rather than N8N_BASIC_AUTH_ACTIVE.

• Backup: take daily PostgreSQL backups with pg_dump and send them to an S3-compatible object store (MinIO, AWS S3).
• n8n data directory backup: back up the n8n_data volume directory with rsync or tar.
• Updates: pull the new n8n image with docker compose pull && docker compose up -d --force-recreate. Always back up before updating.
• Version pinning: use a specific tag like n8nio/n8n:1.x.x in docker-compose.yml instead of n8nio/n8n:latest to prevent unexpected breaking changes.
• Log management: use the json-file Docker log driver and set max-size/max-file limits.

For regular security auditing, reference CIS Benchmarks and automate operating system updates (unattended-upgrades). Monitor n8n Community release notes and apply critical security patches promptly. Our Sora DevOps team helps clients build n8n self-hosting infrastructure correctly from the start — schedule a free discovery call to plan your project.

Frequently Asked Questions

Is Docker required for n8n self-hosting?

Docker is not mandatory; n8n can be installed directly in a Node.js environment. However, n8n officially recommends Docker for its isolated runtime, straightforward updates, and dependency management. Docker Compose is the most practical option.

Should I choose SQLite or PostgreSQL?

SQLite is sufficient for testing and single-user scenarios. For production, always use PostgreSQL: it guarantees data safety across restarts, provides robust backup tooling, and is required for queue mode.

How many server resources does n8n self-hosting need?

For SMB and agency use, 2 vCPU, 4 GB RAM, and 40 GB SSD are appropriate. For heavy workloads or high concurrency, 4 vCPU and 8 GB RAM are recommended; queue mode enables horizontal scaling.

How do I set up HTTPS?

Configure a reverse proxy with Nginx or Caddy. With Nginx, use Certbot to obtain a Let's Encrypt certificate and configure automatic renewal. With Caddy, certificate management is automatic; just write your domain and backend address in the Caddyfile.

How do I scale n8n horizontally?

Enable queue mode: add Redis to docker-compose.yml, set EXECUTIONS_MODE=queue, and define a worker service. Use docker compose up --scale n8n-worker=N to increase the worker count.

How do I update n8n in Docker?

Take a PostgreSQL backup first. Then pull the new image with docker compose pull and restart services with docker compose up -d --force-recreate. Pinning the version tag protects against breaking changes.

How do I back up n8n?

Use pg_dump to take automated daily backups of PostgreSQL and send them to an S3-compatible object store. Back up the n8n data directory (volume: n8n_data) in the same way. Store the encrypted N8N_ENCRYPTION_KEY in a secure vault.

Conclusion

n8n self-hosting with the Docker Compose, PostgreSQL, and Nginx trio gives you an enterprise-grade automation infrastructure. Data sovereignty, predictable costs, and unlimited workflow capacity are what make the self-hosting model clearly superior to the Cloud alternative. Adding queue mode with Redis support makes the system horizontally scalable and reduces the risk of a single point of failure.

Configuring security and backup steps correctly from the start is the foundation of long-term operational health. The combination of UFW, fail2ban, SSH key authentication, and n8n built-in 2FA significantly reduces the attack surface. Our Sora DevOps team can help you plan, deploy, and optimize your n8n self-hosting infrastructure — contact us for a free discovery call.