How to Self-Host n8n: A Docker Compose Setup Guide

Why self-host n8n instead of paying for Cloud

n8n Cloud bills by plan tier and execution volume. Self-hosting the same platform on a $5 to $10 a month VPS removes that ceiling entirely, because the Community edition you run is the free, full-featured build of n8n, not a stripped-down trial.

The tradeoff is that n8n's own documentation is direct about who this is for: self-hosting requires setting up and securing servers, managing resources, and configuring the application yourself. n8n recommends self-hosting for expert users, and recommends n8n Cloud if you are not experienced at managing servers. Read that as a real filter, not boilerplate. Every step past this point assumes you are comfortable in a terminal.

What the free Community edition includes, and where it stops

The Community edition is not a limited trial. It includes the full node and integration library, unlimited workflows and executions, custom JavaScript and Python code nodes, webhooks, cron scheduling, credential management, and error workflows. For a single builder or a small team, that is a complete production automation platform.

Where it stops is team governance, not automation capability. SSO through SAML or LDAP, external secrets stores, log streaming, environments, and fine-grained project roles all sit behind the Business and Enterprise plans. The sharing model is the limit teams hit first without realizing it: on Community, only the instance owner and whoever created a given workflow or credential can open it. A second teammate cannot open someone else's workflow inside the editor without a shared login.

Point a subdomain at your server

n8n only serves traffic over HTTPS once it is reachable from the internet, so DNS comes first. Create an A record on your domain pointing a subdomain (n8n.yourdomain.com, for example) at your server's IP address before you touch Docker.

1. 1.Record type: A
2. 2.Name: the subdomain you want, e.g. n8n
3. 3.Destination: your server's public IP address

Create the project folder and the .env file

Everything for this deployment lives in one directory so it is easy to back up and move later.

Create a project directory and move into it:

Create a .env file with your domain, timezone, and a random encryption key. Generate the key once here and never let it change without a deliberate export/rotate process, covered later in this guide:

Generate a random 64-character string for the encryption key with openssl, rather than leaving it blank and letting n8n auto-generate one you haven't recorded anywhere:

Write the Docker Compose file

This stack runs two containers: n8n itself, and Traefik as a reverse proxy that requests and renews a free TLS certificate automatically. n8n's own hosting docs use this same Traefik pattern, and it is the path with the least manual certificate babysitting.

Create compose.yaml in the same directory:

The n8n_data volume holds n8n's SQLite database and its settings file, including the encryption key if you didn't set one explicitly. traefik_data holds the TLS certificate Traefik requests from Let's Encrypt. For a SQLite-free setup or Caddy instead of Traefik, n8n's own hosting repository has variants for both.

Start n8n and create your admin account

Bring the stack up in the background:

Give Traefik a minute to request the certificate, then confirm both containers are healthy:

Visit https://n8n.yourdomain.com (your actual subdomain and domain). n8n prompts you to create an owner account on first load. Do this immediately; an unclaimed instance sitting open on the internet is the setup mistake that shows up most often in n8n's own community forum.

Protect the one file that can't be recovered

The encryption key you set in your .env file is what n8n uses to encrypt every credential in its database: API keys, OAuth tokens, database passwords, everything a workflow authenticates with. If that key is lost, those credentials do not become hard to recover. They become permanently unreadable. The workflow logic itself survives as plain JSON, but every stored connection has to be rebuilt by hand.

This is why setting N8N_ENCRYPTION_KEY explicitly in step 4 mattered, instead of leaving n8n to auto-generate one. An explicit key is one you can verify you actually have a copy of. Store that copy somewhere with a different failure mode than the server itself: a password manager, or a secrets manager like Vault or AWS Secrets Manager. A backup that lives on the same disk as the server it protects is not a backup.

Back up more than the database

A complete n8n backup has three parts, and most self-hosted setups only cover the first one.

• Back up the n8n_data volume (database and settings file) on a schedule, not just once at setup
• Store the N8N_ENCRYPTION_KEY value separately from the server, in a password manager or secrets manager
• Export workflows as JSON periodically with n8n export:workflow as a human-readable, portable secondary copy
• Test a real restore on a spare instance at least once, before you actually need it

When self-hosting isn't worth the operations overhead

Self-hosting stops making sense the moment the ops work costs you more than n8n Cloud would. If your team needs SSO on day one for compliance reasons, the Community edition fails that requirement immediately, and Business or Enterprise is a faster path than trying to bolt SSO on yourself. If nobody on your team wants to own patching, certificate renewal, and disaster recovery, that ongoing cost is real even though the software itself is free.

A useful gut check: if you would not know how to restore this instance from backup at 2am without help, either fix that before going further, or use n8n Cloud and let someone else carry that risk.

Before you flip this into production

• DNS A record resolves to your server and HTTPS loads without a certificate warning
• N8N_ENCRYPTION_KEY was set explicitly in .env, not left to auto-generate
• You claimed the owner account immediately after first load
• A scheduled backup job covers the n8n_data volume, and the encryption key is stored somewhere else entirely
• You've confirmed whether Community edition's single-owner sharing model is actually enough for your team