n8n mit Docker Compose installieren: Produktionsreifes Setup inkl. SSL, Backup und Updates

n8n Docker Compose ist die Kombination aus der Workflow-Automatisierungsplattform n8n und einer docker-compose.yml, die n8n, Datenbank und Reverse Proxy als reproduzierbaren Container-Stack startet. Mit einem Befehl wie docker compose up -d hast du eine lauffähige Instanz, für den produktiven Einsatz brauchst du zusätzlich SSL, eine Backup-Strategie und einen sauberen Update-Prozess. Genau diese vier Schritte deckt dieser Artikel vollständig ab.

Was ist n8n Docker Compose und für wen lohnt sich Self-Hosting?

n8n Docker Compose bezeichnet den Betrieb der Workflow-Automatisierungsplattform n8n als Container-Stack, definiert in einer docker-compose.yml, statt über die gehostete n8n Cloud. Du bekommst damit volle Kontrolle über Daten, Ausführungslimits und Integrationen, trägst im Gegenzug aber die Verantwortung für Betrieb, Sicherheit und Updates selbst. Für die meisten produktiven Setups ist docker compose der pragmatischste Weg, weil er n8n, Datenbank und Reverse Proxy als einen reproduzierbaren Stack orchestriert, statt Container einzeln mit langen docker run-Befehlen zu starten.

Self-hosted lohnt sich vor allem in drei Fällen: Du verarbeitest sensible Kundendaten und brauchst volle Kontrolle über den Speicherort, du fährst ein hohes Workflow-Volumen und die nutzungsbasierte Preisstruktur der n8n Cloud wird teurer als ein eigener 20-Euro-VPS, oder du brauchst Custom-Nodes und Netzwerkzugriffe, die in der Cloud-Version eingeschränkt sind. Wir setzen bei Kundenprojekten in der Automated KI-Agentur fast ausschließlich self-hosted n8n-Instanzen ein, weil unsere Kunden aus dem Mittelstand oft eigene Compliance-Vorgaben zur Datenhaltung haben. In den folgenden Abschnitten gehen wir den kompletten Lebenszyklus durch: Setup, Absicherung per SSL, Backup-Strategie, Update-Prozess und die Fehler, die in der Praxis wirklich auftreten. Wer sich generell für die Automatisierung von Geschäftsprozessen interessiert, findet in unserem Artikel zu Workflow Automation den größeren Kontext dazu, wo n8n in eine automatisierte Prozesslandschaft passt.

Voraussetzungen: Server, Docker, Docker Compose und Domain

Für eine produktive n8n-Instanz mit PostgreSQL und moderatem Workflow-Volumen (bis etwa 5.000 Executions pro Tag) reichen 2 vCPUs, 4 GB RAM und 40 GB SSD-Storage bei Anbietern wie Hetzner, Contabo oder DigitalOcean. Prüfe deine Docker-Version mit

docker --version && docker compose version

Du brauchst mindestens Docker 24.x und Compose V2 (das Plugin, nicht das alte docker-compose mit Bindestrich). Fehlt Docker, installierst du es über das offizielle Installationsskript:

curl -fsSL https://get.docker.com | sh

Zusätzlich brauchst du eine Domain mit einem A-Record, der auf die IP deines Servers zeigt, sowie offene Ports 80 und 443 für die automatische Zertifikatsausstellung über Let’s Encrypt. Zwei Dinge solltest du vor dem ersten Schritt in der Checkliste haben: eine .env-Datei, in der du alle environment variables zentral pflegst, statt sie hart in die docker-compose.yml zu schreiben, und einen SSH-Zugang mit einem non-root User für den Deploy.

Schritt-für-Schritt: n8n mit PostgreSQL per Docker Compose installieren

Die offizielle n8n-Dokumentation zum Docker-Hosting zeigt die Grundlagen. Wir gehen einen Schritt weiter und bauen direkt den vollständigen Stack mit PostgreSQL statt der Default-SQLite-Datenbank, weil SQLite bei parallelen Workflow-Ausführungen schnell zum Bottleneck wird und Locking-Fehler produziert.

Lege ein Projektverzeichnis an und wechsle hinein:
```
mkdir -p ~/n8n-stack && cd ~/n8n-stack
```

Erstelle die .env-Datei mit allen environment variables:

cat > .env << 'EOF'
# Postgres
POSTGRES_USER=n8n
POSTGRES_PASSWORD=ein-sehr-langes-zufallspasswort
POSTGRES_DB=n8n # n8n
N8N_ENCRYPTION_KEY=generiere-mit-openssl-rand-hex-32
N8N_HOST=n8n.deinedomain.de
WEBHOOK_URL=https://n8n.deinedomain.de/
GENERIC_TIMEZONE=Europe/Berlin
N8N_VERSION=1.68.0
EOF

Generiere den Encryption Key nicht per Hand, sondern mit

openssl rand -hex 32

Dieser Key verschlüsselt alle in n8n gespeicherten Credentials. Verlierst du ihn, sind bestehende Credential-Einträge nach einer Neuinstallation unbrauchbar.

Lege die docker-compose.yml an:

cat > docker-compose.yml << 'EOF'
version: "3.8" services: postgres: image: postgres:16-alpine restart: unless-stopped environment: - POSTGRES_USER=${POSTGRES_USER} - POSTGRES_PASSWORD=${POSTGRES_PASSWORD} - POSTGRES_DB=${POSTGRES_DB} volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"] interval: 10s timeout: 5s retries: 5 n8n: image: docker.n8n.io/n8nio/n8n:${N8N_VERSION} restart: unless-stopped depends_on: postgres: condition: service_healthy environment: - DB_TYPE=postgresdb - DB_POSTGRESDB_HOST=postgres - DB_POSTGRESDB_PORT=5432 - DB_POSTGRESDB_DATABASE=${POSTGRES_DB} - DB_POSTGRESDB_USER=${POSTGRES_USER} - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD} - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY} - N8N_HOST=${N8N_HOST} - WEBHOOK_URL=${WEBHOOK_URL} - GENERIC_TIMEZONE=${GENERIC_TIMEZONE} - N8N_PROTOCOL=https - N8N_PORT=5678 volumes: - n8n_data:/home/node/.n8n volumes: postgres_data: n8n_data:
EOF

Beachte den festen Version-Tag ${N8N_VERSION} statt latest. Dazu später mehr im Update-Abschnitt. Die beiden volumes-Einträge sind entscheidend: postgres_data hält die Datenbank persistent, n8n_data speichert Credentials-Metadaten und lokale Dateien. Ohne diese Volumes verlierst du bei jedem Container-Neustart sämtliche Workflows.

Starte den Stack und prüfe die Logs:
```
docker compose up -d
docker compose logs -f n8n
```
Ein erfolgreicher Start zeigt in den Logs die Zeile Editor is now accessible via: http://localhost:5678/ gefolgt von n8n ready on 0.0.0.0, port 5678. Läuft der Postgres-Container noch beim Healthcheck, wartet n8n dank depends_on mit condition: service_healthy automatisch, statt mit einem Connection-Fehler abzubrechen.

An diesem Punkt läuft n8n lokal auf Port 5678, aber noch ohne HTTPS. Für Webhooks, OAuth-Integrationen und den produktiven Einsatz reicht das nicht aus, dazu kommen wir im nächsten Abschnitt.

Aus der Praxis in Ihren Betrieb

Was wäre bei Ihnen automatisierbar?

Im kostenlosen Prozess-Audit zeigen wir Ihnen in 30 Minuten konkret, welche 3 Automationen sich bei Ihnen sofort lohnen, mit Einsparungs-Schätzung als PDF.

Prozess-Audit sichern

Produktiv-Setup: SSL und Reverse Proxy mit Traefik einrichten

Ohne https/ssl funktionieren OAuth-Callbacks von Google, Microsoft oder Slack in n8n schlicht nicht, weil diese Anbieter verschlüsselte Redirect-URLs verlangen. Auch eingehende Webhooks von externen Diensten wie Stripe oder Typeform laufen ins Leere, wenn die webhook url nicht auf ein gültiges Zertifikat zeigt. SSL ist hier keine Zusatzoption, sondern eine harte Voraussetzung für den produktiven Betrieb.

Traefik übernimmt als reverse proxy die automatische Zertifikatsausstellung über Let's Encrypt und leitet Anfragen an den n8n-Container weiter. Erweitere deine docker-compose.yml um den Traefik-Service und die passenden Labels am n8n-Container:

 traefik: image: traefik:v3.1 restart: unless-stopped command: - --providers.docker=true - --providers.docker.exposedbydefault=false - --entrypoints.web.address=:80 - --entrypoints.websecure.address=:443 - --certificatesresolvers.le.acme.httpchallenge=true - --certificatesresolvers.le.acme.httpchallenge.entrypoint=web - [email protected] - --certificatesresolvers.le.acme.storage=/letsencrypt/acme.json ports: - "80:80" - "443:443" volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - traefik_certs:/letsencrypt n8n: labels: - traefik.enable=true - traefik.http.routers.n8n.rule=Host(`n8n.deinedomain.de`) - traefik.http.routers.n8n.entrypoints=websecure - traefik.http.routers.n8n.tls.certresolver=le - traefik.http.services.n8n.loadbalancer.server.port=5678

Ergänze traefik_certs im volumes-Block und entferne die direkte Port-Freigabe am n8n-Service, da der Zugriff jetzt ausschließlich über Traefik läuft. Setze WEBHOOK_URL in der .env exakt auf die HTTPS-Domain, sonst generiert n8n intern weiterhin http-Links für neue Webhook-Nodes, was bei externen Diensten zu stillen Fehlschlägen führt. Nach docker compose up -d dauert die erste Zertifikatsausstellung meist 10 bis 30 Sekunden, prüfbar über docker compose logs traefik.

Backup, Restore und Updates: n8n-Instanz sicher aktualisieren

Zwei Dinge musst du sichern: die PostgreSQL-Datenbank mit allen Workflows, Credentials und Execution-Historien, und das n8n_data-Volume mit lokalen Konfigurationsdateien. Ein einfacher, zuverlässiger Ansatz ist ein täglicher Cronjob, der einen Postgres-Dump zieht und das n8n-Volume archiviert:

0 3 * * * docker exec n8n-stack-postgres-1 pg_dump -U n8n n8n | gzip > /backups/n8n-db-$(date +\%F).sql.gz && tar czf /backups/n8n-data-$(date +\%F).tar.gz -C /var/lib/docker/volumes/n8n-stack_n8n_data/_data .

Lade die Backup-Dateien zusätzlich per rclone oder rsync auf einen externen Speicher wie Backblaze B2 oder Hetzner Storage Box hoch. Ein lokales Backup auf demselben Server schützt dich nicht, wenn der Server selbst ausfällt. In unserem eigenen Setup für Kundenprojekte laufen diese Cronjobs mit einer 14-Tage-Rotation, das hat uns bei einem Kunden aus dem E-Commerce-Bereich nach einem versehentlichen Workflow-Löschvorgang die komplette Wiederherstellung in unter 15 Minuten ermöglicht.

Der Restore-Prozess läuft in drei Schritten: Stoppe zuerst den Stack mit docker compose down, spiele dann den Datenbank-Dump zurück mit

gunzip -c n8n-db-2026-08-01.sql.gz | docker exec -i n8n-stack-postgres-1 psql -U n8n -d n8n

und entpacke anschließend das Volume-Archiv in das entsprechende Docker-Volume-Verzeichnis, bevor du den Stack mit docker compose up -d neu startest.

Beim Update-Prozess ist der wichtigste Punkt, den kaum eine Anleitung erwähnt: Pinne den image tag latest niemals in einer produktiven Umgebung. Mit N8N_VERSION=latest holst du bei jedem Neustart eine unbekannte Version, die Breaking Changes an Node-Verhalten oder der Datenbankstruktur enthalten kann, ohne dass du es vorher testest. Ändere stattdessen gezielt den Wert in deiner .env, etwa von 1.68.0 auf 1.69.2, teste den Wechsel zuerst auf einer Staging-Instanz mit einer Kopie deiner Produktionsdaten und rolle erst danach mit docker compose pull && docker compose up -d auf Produktion aus.

Troubleshooting: Die häufigsten Fehler und ihre Lösungen

Die meisten Probleme im laufenden Betrieb lassen sich mit docker compose logs -f n8n und docker compose logs -f postgres systematisch eingrenzen. Starte immer dort, bevor du an der Konfiguration herumänderst. Aus über 30 Automatisierungsprojekten kennen wir drei Fehlerbilder, die immer wieder auftauchen:

Fehlermeldung	Ursache	Lösung
`ECONNREFUSED postgres:5432`	Postgres-Container noch nicht bereit oder falscher Hostname in environment variables	Healthcheck mit `depends_on: condition: service_healthy` nutzen, DB_POSTGRESDB_HOST auf Servicenamen prüfen
`EACCES: permission denied, mkdir '/home/node/.n8n'`	Volume-Verzeichnis gehört root, n8n läuft als non-root user node	Volume-Ownership korrigieren mit `docker run --rm -v n8n-stack_n8n_data:/data alpine chown -R 1000:1000 /data`
Webhook antwortet mit 404 trotz aktivem Workflow	webhook url zeigt noch auf http oder falsche Domain	WEBHOOK_URL in .env korrigieren, Container neu starten, Workflow einmal neu aktivieren
`Mismatching encryption keys`	N8N_ENCRYPTION_KEY nach Neuinstallation geändert oder nicht aus Backup übernommen	Encryption Key immer zusammen mit der Datenbank sichern, nie neu generieren bei bestehenden Daten

Der Encryption-Key-Mismatch verdient besondere Aufmerksamkeit: Sicherst du zwar die Postgres-Datenbank, vergisst aber den ursprünglichen N8N_ENCRYPTION_KEY zu dokumentieren, verlierst du nach einem Restore auf einem neuen Server sämtliche gespeicherten Credentials, obwohl die Workflows selbst intakt bleiben. Lege den Key deshalb zusätzlich in einem Passwort-Manager ab, getrennt vom Server-Backup.

Best Practices für sicheren self-hosted Betrieb

Über den reinen Betrieb hinaus lohnen sich einige Anpassungen, die deine Instanz langfristig stabiler und sicherer machen:

Non-root user erzwingen: Das offizielle n8n-Image läuft bereits standardmäßig als non-root user node, prüfe das aber explizit mit docker compose exec n8n whoami nach jedem Update, da manche Custom-Images diese Einstellung überschreiben.
Secrets nicht im Klartext versionieren: Halte die .env-Datei aus der Versionskontrolle raus über einen Eintrag in .gitignore, und nutze für Teams einen Secret-Manager wie Doppler oder HashiCorp Vault statt Klartext-Dateien auf dem Server.
Queue Mode für Skalierung aktivieren: Ab etwa 50 gleichzeitig laufenden Workflows stößt die Standard-Konfiguration an Grenzen. Mit EXECUTIONS_MODE=queue und zusätzlichen Worker-Containern, die über Redis kommunizieren, verteilst du die Last auf mehrere Prozesse.
Healthchecks und restart-Policy setzen: restart: unless-stopped sorgt dafür, dass Container nach einem Server-Neustart automatisch wieder hochfahren, kombiniert mit Healthchecks erkennt Docker hängende Container frühzeitig.
Image tag latest konsequent vermeiden: Auch bei Traefik und Postgres gilt dieselbe Regel wie bei n8n selbst, feste Versionen verhindern überraschende Breaking Changes bei einem einfachen Neustart des Stacks.

Wer dieses Setup nicht selbst betreiben will oder beim Queue-Mode-Rollout Unterstützung braucht, findet über unser AI Consulting praktische Begleitung von der Architektur bis zum produktiven Rollout.

FAQ zu n8n Docker Compose

Ist n8n mit Docker Compose kostenlos oder fallen Lizenzkosten an?

n8n läuft unter der Sustainable Use License kostenlos, solange du es nicht als kommerziellen SaaS-Dienst für Dritte weiterverkaufst. Für den self-hosted Betrieb per docker compose zahlst du ausschließlich die Serverkosten, keine n8n-Lizenzgebühr. Enterprise-Features wie SSO oder erweiterte Rechteverwaltung erfordern eine separate n8n Enterprise-Lizenz, die für die meisten Self-Hoster nicht nötig ist.

Wie viel Server-Ressourcen (RAM/CPU) braucht n8n im Produktivbetrieb realistisch?

Für ein kleines bis mittleres Setup mit einigen Dutzend aktiven Workflows reichen 2 vCPUs und 4 GB RAM meist aus, wobei PostgreSQL und Traefik den größten Teil des zusätzlichen Speicherbedarfs ausmachen. Steigt das Volumen auf mehrere Tausend Executions pro Tag oder nutzt du speicherintensive Nodes wie große HTTP-Response-Verarbeitungen, solltest du auf 8 GB RAM aufstocken oder direkt in den Queue Mode mit separaten Worker-Containern wechseln.

Kann ich von SQLite auf PostgreSQL migrieren, ohne bestehende Workflows zu verlieren?

Ja, n8n bietet dafür kein automatisches Migrationstool, aber den Weg über Export und Import: Exportiere alle Workflows und Credentials über die n8n-CLI im Container mit n8n export:workflow --all --output=/backup/workflows.json und n8n export:credentials --all --output=/backup/credentials.json, stelle danach den Stack auf PostgreSQL um und importiere die Dateien mit den entsprechenden n8n import:-Befehlen zurück in die neue Datenbank.

Mehr zu Automatisierungsthemen und weiteren n8n-Setups findest du in unserem Blog, und wer die Grundkonzepte hinter Workflow-Tools wie n8n vertiefen will, liegt mit unserer Übersicht zu KI-Chatbots für Unternehmen ebenfalls richtig, da viele n8n-Workflows genau solche Chatbot-Integrationen ansteuern.