How to install n8n self-hosted with Docker

Actualizado: 2026-05-03

n8n is the low-code automation platform that has grown most in the self-hosted world over the last two years. It offers a serious alternative to Zapier and Make for organizations wanting to control their own flows without paying per-integration fees. This article covers the concrete install with Docker Compose, the architecture decisions to make at start, and the points where most people stumble the first time.

Key takeaways

• The first important decision is the database: start directly with PostgreSQL, not SQLite, for any deployment with more than one flow or user.
• Queue mode (separating web process from workers via Redis) is needed above five frequently-executed flows.
• N8N_ENCRYPTION_KEY is the most critical variable: generate it once, store it safely, and never change it.
• Public webhooks require WEBHOOK_URL to point exactly to the public domain reachable from the internet, not localhost.
• /home/node/.n8n persistence must go on a named volume; several teams have lost flows and credentials by forgetting this.

What n8n does and when self-hosting makes sense

n8n lets you connect tools via visual flows where each node is an action, a trigger, or a transformation. There are nodes for hundreds of common services: Google Workspace, Slack, databases, generic HTTP APIs, message queues, WhatsApp, email, object storage. When a node doesn’t exist, a code node allows writing JavaScript or Python for almost anything.

Self-hosting makes sense for three main reasons:

• Sensitive data control: if your flows move customer data, contracts, or financial data, having them bouncing between external SaaS and internal systems is an exposure not all organizations accept.
• Cost: the self-hosted version doesn’t charge per flow execution, which for high volumes is a substantial saving.
• Flexibility: integrating with internal systems, private APIs, or local databases is much easier when n8n runs inside the same network.

Where it doesn’t make sense is when flows are few and simple, with few external integrations and low volume. In that scenario, the operational friction of maintaining another piece of infrastructure outweighs cost savings.

Database choice

The first decision at install time is the database. n8n supports SQLite, PostgreSQL, and MySQL. The default is SQLite, which works fine for small single-process installs with few flows.

The recommendation, for almost any deployment with more than one flow or user, is to start directly with PostgreSQL. Migrating from SQLite to PostgreSQL later is possible but awkward, and PostgreSQL advantages appear even at small scales: better backups, clearer introspection, and the ability to enable queue mode later without remigrating.

Queue mode for serious loads

By default, n8n executes flows in the same process serving the web interface. With long or many simultaneous flows, problems appear: the interface slows down, executions can block, and horizontal scaling is impossible.

The solution is queue mode, which separates the web process from the worker process and connects them through a Redis queue. In this mode the interface stays fast even under load.

Configuration consists of defining two Docker services with the same image but different variables:

• The main one with EXECUTIONS_MODE=queue and QUEUE_BULL_REDIS_HOST pointing at Redis.
• The workers with the n8n worker command.

Critical environment variables

• N8N_ENCRYPTION_KEY: the key used to encrypt credentials in the database. If this key changes, all stored credentials become unusable. Generate it once, save it safely, never change it.
• N8N_HOST and WEBHOOK_URL: tell n8n which domain it is accessed from and under which URL public webhooks should be generated. If these don’t match reality, external webhooks will not work.
• N8N_RUNNERS_ENABLED: turns on the isolated executor for user code. From recent versions this is the recommended default for any deployment running untrusted code.

Traefik or Nginx in front

In most self-hosted installs, n8n runs behind a proxy like Traefik or Nginx. Pay attention to proxy timeout: some flows can take minutes, especially if calling slow external APIs. The default Nginx 60-second timeout can cut these executions, producing 504 errors. Raise it to several minutes for flow execution paths.

Typical friction points

Three problems almost everyone hits the first time:

• Data persistence: the n8n container stores data at /home/node/.n8n, which must go on a persistent volume. Use named volumes and have regular database backups.
• Credential handling: the backup process must include both the database and the encryption key. If you restore on another server with a different key, all credentials are useless.
• Active vs. inactive flows: a flow created but not activated does not run. The distinction is a toggle at the top of the editor.

Conclusion

The decision to self-host n8n comes down to one question: does control over data and savings on executions justify the operational cost of maintaining another piece of infrastructure? For medium volumes and sensitive data, the answer is usually yes.