self hosting
n8n Docker Installation: Persistent Volume, Timezone, and Production Readiness
Use Docker for most self-hosted n8n installs when you want an isolated runtime, persistent data, and simpler environment management.
Independent third-party notes. n8n is a trademark of its owner and is referenced only for compatibility and troubleshooting context.
Quick Answer
Use Docker for most self-hosted n8n installs when you want an isolated runtime, persistent data, and simpler environment management.
Problem Pattern
The user can start n8n in Docker but has not yet made the deployment durable, reachable from external services, or safe for real workflows.
Key Facts
- Recommended install method
- Docker is recommended by n8n for most self-hosting needs.
- Default port
- The standard container command exposes n8n on port 5678.
- Persistent data path
- The Docker volume should mount to /home/node/.n8n.
- Timezone variables
- Set both TZ and GENERIC_TIMEZONE so system time and schedule-oriented nodes align.
Recommended Steps
- Create a Docker volume for n8n data.
- Run the official n8n Docker image and map host port 5678 to container port 5678.
- Set TZ and GENERIC_TIMEZONE for your deployment region.
- Mount the persistent volume to /home/node/.n8n.
- Open http://localhost:5678 after the container starts.
Verification
- The container remains running after startup.
- http://localhost:5678 loads the n8n UI.
- Workflows and credentials survive a container restart.
Warnings
- Self-hosting requires server, container, security, resource, and backup knowledge.
- Do not run production n8n without persistent storage for /home/node/.n8n.
Best For
- Local testing, small self-hosted installs, and first production prototypes.
- Users who want a simple containerized n8n runtime before adding Postgres or Redis.
- VPS deployments where persistence, backups, HTTPS, and public webhook URLs will be added next.
Not For
- High-volume production workloads that already need queue mode.
- Teams that cannot maintain server security, backups, and upgrades.
- Deployments that need managed hosting and support from day one.
Common Mistakes
- Running the container without a persistent volume for /home/node/.n8n.
- Testing on localhost and then forgetting that external webhook providers cannot reach localhost.
- Setting only TZ or only GENERIC_TIMEZONE instead of keeping both aligned.
- Treating the Docker command as a full production deployment plan.
Examples
docker volume create n8n_data
docker run -it --rm \
--name n8n \
-p 5678:5678 \
-e TZ=Asia/Shanghai \
-e GENERIC_TIMEZONE=Asia/Shanghai \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8nPersistent volume: /home/node/.n8n
Public HTTPS domain: configured
WEBHOOK_URL: points to public HTTPS base URL
Backups: tested restore path
Upgrade plan: documented
Monitoring: container health and disk usage checkedFAQ
Can I run n8n Docker without a volume?
Only for disposable testing. For any real workflow, mount persistent storage to /home/node/.n8n so workflows, credentials, and default SQLite data survive container replacement.
Is Docker enough for production?
Docker can be a good starting point, but production also needs HTTPS, backups, resource monitoring, secure secrets, upgrade planning, and often Postgres.
Why does my webhook URL show localhost?
The instance does not know its public base URL. Configure public endpoint settings such as WEBHOOK_URL when serving n8n behind a domain or reverse proxy.