Self-Hosting n8n with Docker Compose: Complete Guide for German Servers

n8n can be installed on your own server with Docker Compose in a few steps: you create a compose file and an .env file with the credentials, define a volume for the persistent data, and start the stack with a single command. For production use, most operators switch from the bundled SQLite database to PostgreSQL, because multiple simultaneously running workflows and regular backups work more reliably with it. This article shows the structure of the compose file, the required environment variables, the volumes, and the update process. As of: July 2026.

How do you install n8n with Docker Compose?

The installation runs through a compose.yaml file that starts the n8n container, combined with an .env file for the server-specific values. On a Linux server, first check whether Docker and Docker Compose are installed, for example with the commands docker --version and docker compose version. Then create a project directory with the compose.yaml, the .env file, and a subfolder local-files for file exchange between n8n and the host. The start is done with the command docker compose up -d, after which n8n is reachable via the configured domain or, for a simple single-container installation without a reverse proxy, at http://localhost:5678. The official n8n documentation provides a ready-made setup for this with Docker Compose, which also includes Traefik as a reverse proxy for TLS certificates.

SQLite or PostgreSQL: which database makes sense?

By default, n8n uses SQLite and stores credentials, workflows, and the execution history without additional configuration in the file database.sqlite in the .n8n directory. To switch to PostgreSQL, set the appropriate environment variables in the compose file, as described in the documentation on database selection.

• DB_TYPE: set to postgresdb to replace SQLite
• DB_POSTGRESDB_HOST and DB_POSTGRESDB_PORT: address and port of the Postgres server
• DB_POSTGRESDB_DATABASE: name of the database, default value is n8n
• DB_POSTGRESDB_USER and DB_POSTGRESDB_PASSWORD: credentials for the database
• DB_POSTGRESDB_SCHEMA: schema within the database, default value is public

Important: Even with PostgreSQL, the volume for the directory /home/node/.n8n remains necessary, because the encryption key for credentials is still stored there.

What belongs in the .env file?

The .env file bundles all the values that differ from server to server, so that the compose.yaml itself remains unchanged. According to the official guide on Docker installation, at least the following variables belong there.

• DOMAIN_NAME and SUBDOMAIN: together determine the address at which n8n is reachable, for example n8n.example.com
• GENERIC_TIMEZONE and TZ: control the time zone for schedule nodes and system commands
• SSL_EMAIL: contact address for automatic certificate issuance via Traefik
• N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS: should be set to true to secure the permissions of the configuration files

Since this file contains passwords and credentials, it does not belong in a public Git repository.

Which volumes and directories does n8n need?

For permanent operation, several storage locations are relevant, which must be preserved on every restart.

• n8n_data: mounted on /home/node/.n8n, contains the SQLite database, if used, as well as the encryption key
• traefik_data: stores the TLS certificates if you use the bundled reverse proxy
• local-files: local directory on the host for file exchange, connected via the variable N8N_RESTRICT_FILE_ACCESS_TO

Without these volumes, workflows, credentials, and certificates are lost every time the container is rebuilt.

How do you update n8n with Docker Compose?

An update runs through three commands in the directory of the compose file: docker compose pull downloads the new image version, docker compose down stops the running stack, and docker compose up -d restarts it with the current image. The volumes remain unaffected, so workflows and credentials are preserved. Anyone who wants to pin a specific version instead of automatically updating to the latest stable version can specify a concrete version tag in the compose.yaml, according to the documentation for example docker.n8n.io/n8nio/n8n:1.81.0, instead of the tag next for unstable beta versions. Anyone who wants a clean configuration from the start is better off planning thoroughly once instead of fixing server problems later. NordFlux takes care of exactly that as part of the n8n setup at a fixed price, including the decision between SQLite and PostgreSQL matching actual usage.

Frequently asked questions about n8n Docker Compose

Do I need my own domain to run n8n with Docker Compose?

No, that is not mandatory. For a simple single-container installation, a mapped volume and port 5678 are sufficient, n8n is then reachable locally at http://localhost:5678. A domain only becomes necessary if you want to use the setup described in the official guide with Traefik as a reverse proxy and an automatic TLS certificate.

Where does n8n store my credentials and workflows?

Everything is located in the mounted volume that points to the directory /home/node/.n8n in the container. When using SQLite, the database file is located there, and regardless of the database choice, so is the encryption key for stored credentials. Without this volume, all data is lost at the next container restart.

How do I update n8n without data loss?

The sequence docker compose pull, docker compose down, and docker compose up -d updates the image without touching the volumes. Since workflows, credentials, and the database are located in the volumes, they are preserved during the update. Before larger version jumps, it is nevertheless worth checking the release notes, because environment variables can change between versions.

Can I choose between a fixed n8n version and the beta version?

Yes, the Docker images are published with different tags. A specific version tag such as 1.81.0 pins a stable version, while the tag next provides the unstable beta version for anyone who wants to test new features in advance. For production servers, a pinned version tag is the more reliable choice.