self hosting
n8n Docker Compose Setup for Self-Hosting: Volume, .env, Postgres, and Webhooks
Use Docker Compose when you want a repeatable n8n deployment file, especially once you add Postgres, Redis, reverse proxy, or backups.
Independent third-party notes. n8n is a trademark of its owner and is referenced only for compatibility and troubleshooting context.
Quick Answer
Use Docker Compose when you want a repeatable n8n deployment file, especially once you add Postgres, Redis, reverse proxy, or backups.
Problem Pattern
The user is moving from a one-line Docker run command to a repeatable self-hosted deployment and needs to avoid losing data or generating bad webhook URLs.
Key Facts
- Best fit
- Docker Compose is best for repeatable multi-service deployments.
- Persistent storage
- n8n data still needs a persistent volume.
- Source repository
- n8n points users to the n8n-hosting repository for Compose configurations.
Recommended Steps
- Start from an official or clearly maintained Compose example.
- Define the n8n service with image, ports, environment variables, and volumes.
- Add Postgres when you need a more production-oriented database setup.
- Keep secrets out of the committed Compose file by using an environment file or secret manager.
- Run the stack, then verify the UI and persistence.
Verification
- docker compose ps shows the n8n service healthy or running.
- The n8n UI is reachable at the configured host and port.
- Restarting the stack does not delete workflows.
Warnings
- A Compose file is not a full production security plan.
- Back up both the database and the n8n data directory before upgrades.
Best For
- Repeatable self-hosted deployments that need more than one service.
- Teams adding Postgres, Redis, reverse proxy, or backup jobs.
- Users who want deployment settings stored in files rather than one long Docker command.
Not For
- One-off local testing where a single Docker command is enough.
- Users who do not yet understand volumes, env files, and container networking.
- Managed-hosting use cases where infrastructure ownership is unwanted.
Common Mistakes
- Committing .env files that contain encryption keys, database passwords, or API credentials.
- Keeping workflows in a container filesystem instead of a volume.
- Using Compose without a backup and restore process.
- Changing env values without recreating or restarting the affected services.
Examples
services:
n8n:
image: docker.n8n.io/n8nio/n8n
ports:
- "5678:5678"
env_file:
- .env
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:TZ=Asia/Shanghai
GENERIC_TIMEZONE=Asia/Shanghai
N8N_HOST=automation.example.com
N8N_PROTOCOL=https
WEBHOOK_URL=https://automation.example.com/FAQ
Should I put secrets directly in docker-compose.yml?
Avoid it. Use an ignored .env file, platform secrets, or your deployment system's secret manager.
When should I add Postgres?
Add Postgres when the instance matters, workflow volume grows, queue mode is planned, or you want a more explicit database backup process.
Does Compose solve HTTPS?
Not by itself. You still need a reverse proxy, TLS termination, or another HTTPS layer.