How to Self-Host n8n: Docker Compose, TLS and Backups
Here is how to self-host n8n — with Docker Compose, a reverse proxy plus TLS, clean persistence and tested backups. The result: your workflow automation runs on your own server in the EU, with no per-execution limit.
See n8n hostingn8n is an open-source alternative to Zapier and Make: a workflow automation tool that connects hundreds of services through nodes. Self-hosted, you pay no surcharge per execution, and your data — often API keys and customer records — never leaves your server.
Prerequisites
A small cloud server with 2 vCPUs and 4 GB of RAM is enough to start; for many concurrent workflows, budget more RAM and local NVMe . You also need Docker, Docker Compose and a domain for the TLS certificate.
Set up n8n with Docker Compose
- Prepare the server and Docker: set up a cloud server with a recent Linux, install Docker and Docker Compose, and point your domain's DNS record at the server IP.
- Create docker-compose.yml: define the n8n service, a persistent volume for the /home/node/.n8n directory, and — for production — PostgreSQL as the database instead of the default SQLite.
- Set environment variables: configure host, protocol (https), timezone and a fixed encryption key; additionally enable basic auth or the native user login.
- Add a reverse proxy and TLS: put Nginx or Caddy in front, terminate HTTPS via Let's Encrypt, and correctly pass through the WebSocket connections the editor UI needs.
- Start the stack: bring it up with docker compose up -d, check the logs, and open the editor UI on your domain.
- Persistence and backups: regularly back up the n8n volume and the PostgreSQL database, secured with server-level snapshot backups .
- Run updates: pin the n8n image to a fixed version, take a backup before every update, and store the encryption key safely — without it, saved credentials are lost.
Cost: self-host vs. n8n Cloud
n8n Cloud bills by executed workflows — predictable at low volume, expensive at high volume. Self-hosted, you pay only for the server regardless of how many executions run; in exchange you carry the operations and maintenance yourself.
| Criterion | Self-hosted (Bthorio) | n8n Cloud |
|---|---|---|
| Billing | Fixed server price | By executed workflows |
| Cost at high volume | Constant | Grows with executions |
| Data sovereignty | Data stays on your server (EU) | Hosted by the provider |
| Maintenance | On you | Handled by the provider |
| Customizability | Full (custom nodes, environment) | Limited |
Secure and operate it in production
A self-hosted n8n often processes credentials and customer data — so it deserves to be secured and monitored, not just started once. These points separate a stable setup from one that causes trouble after a few weeks.
- Protect access: never expose the editor UI without authentication; basic auth or login plus TLS are mandatory.
- Secure webhooks: verify public webhook URLs with a signature or token so no foreign calls trigger your workflows.
- Cap resources: set CPU and RAM limits on the container so a runaway workflow does not block the whole server.
- Prune executions: delete old execution data regularly, otherwise the database grows unnoticed.
- Monitor failures: have failed workflows notify you actively instead of being overlooked in the log.
- Set the timezone correctly so scheduled triggers fire at the expected local time rather than in UTC.