n8n in Docker-Containern – sinnvoll oder übertrieben?
n8n will Automatisierung einfach machen. Lokal kurz getestet, läuft. Doch sobald mehr als ein Bastelprojekt entsteht, wird's schnell nervig: Abhängigkeiten, Datenbank, Updates – die Liste wächst. Docker hilft, den ganzen Kram zu trennen. Keine kaputten Paketversionen, kein Ärger beim Serverumzug. Wer einmal versucht hat, n8n samt PostgreSQL und Node auf einem Shared Hosting zu installieren, weiß: Container sind nicht nur Hype.
In Agenturprojekten oder bei mehreren n8n-Instanzen ist die Isolation fast Pflicht. Aber: Ein Container allein reicht nicht. Ohne Backup und Update-Routine bleibt’s eine tickende Zeitbombe. Typisch in der Praxis: Installation läuft noch, Backup gibt’s erst nach dem ersten Datenverlust. Muss nicht sein.
Vorab: System fit machen
Docker und Compose sollten aktuell sein. 2026 ist alles unter Docker 24.x und Compose 2.x zu alt. Für ein Testsystem reichen 2 GB RAM. Im Produktivbetrieb sind 4+, besser 8 GB längst kein Luxus. n8n nutzt per Default SQLite – für Demo ok, für Produktionsdaten eher suboptimal. PostgreSQL ist zuverlässiger. Mit Docker Compose bleibt die Einrichtung überschaubar, selbst ohne Admin-Kenntnisse.
Beispiel-Setup mit Docker Compose
So läuft n8n samt PostgreSQL – nichts Kompliziertes, aber praxistauglich:
Code:
version: '3.8'
services:
n8n:
image: n8nio/n8n:latest
restart: unless-stopped
ports:
- '5678:5678'
environment:
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8nuser
- DB_POSTGRESDB_PASSWORD=geheimespasswort
- N8N_BASIC_AUTH_ACTIVE=true
- N8N_BASIC_AUTH_USER=admin
- N8N_BASIC_AUTH_PASSWORD=starkespasswort
- GENERIC_TIMEZONE=Europe/Berlin
depends_on:
- postgres
volumes:
- n8n_data:/home/node/.n8n
postgres:
image: postgres:15-alpine
restart: unless-stopped
environment:
- POSTGRES_DB=n8n
- POSTGRES_USER=n8nuser
- POSTGRES_PASSWORD=geheimespasswort
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
n8n_data:
pgdata:Starten, testen, Fehler finden
Mit `docker compose up -d` geht es los. Logs per `docker compose logs -f n8n` – sind Fehler da, sieht man sie meist sofort. Oberfläche auf host erreichbar? Anmeldung klappt? Workflow-Test, Datenbankverbindung. Typische Fehler: Datenbank falsch konfiguriert, Passwörter zu schwach, Auth vergessen. Schnell behoben, wenn man es gleich kontrolliert.
Updates: Kein Blindflug
Das offizielle Image `n8nio/n8n:latest` wird regelmäßig neu gebaut. Wer im Produktivbetrieb arbeitet, sollte trotzdem nicht einfach aktualisieren. Was sich bewährt hat:
- Immer vor Updates ein Backup – und zwar wirklich. Datenbank und Volume.
- Neues Image per `docker compose pull` holen
- Neustart: `docker compose down && docker compose up -d`
Wer mag, baut sich das als Cronjob. Aber: Bei größeren Updates unbedingt die Release Notes lesen. Gab schon mehr als einen Workflow, der nach einem Update plötzlich tot war – weil sich Nodes geändert hatten.
Backups – nicht nur Datenbank, auch Volumes
Daten liegen in den Volumes `n8n_data` und `pgdata`. Ohne Backup ist beim Crash alles weg. Ein funktionierendes Volume-Backup sieht zum Beispiel so aus:
- `docker run --rm -v n8n_data:/data -v $(pwd):/backup alpine tar czf /backup/n8n_data_$(date +%F).tgz -C /data .`
- Für `pgdata` das gleiche Spiel
Regelmäßig sichern, am besten nicht nur lokal. Wer einmal einen kaputten Server hatte und nur ein uraltes Backup fand, weiß: Backups altern nicht wie Wein.
Meine Einschätzung nach fast 30 Jahren Webprojekten
Docker hat großen Projekten viele Probleme abgenommen. Versionen, Abhängigkeiten, Deployments – deutlich entspannter als früher. Trotzdem: In Agenturen und Teams tauchen immer dieselben Fehler auf. Backups? Oft nur eingerichtet, nie getestet. Updates? Schnell mal „latest“ gezogen, ohne Staging. Das rächt sich. Einmal zu sorglos – und plötzlich sind Kunden-Workflows kaputt.
Bei mehreren Instanzen empfiehlt sich mindestens ein Staging-System. Vor allem, weil n8n-Updates gern mal die API anpassen. Gesehen: Nach einem Update liefen 3 von 12 Kunden-Workflows nicht mehr. Ursache: Node geändert, Mapping kaputt, keine Tests vorher. Ärgerlich – und komplett vermeidbar.
Einzelkämpfer unterschätzen oft, wie fragil SQLite ist. Schnell eingerichtet, aber kein Vergleich zu PostgreSQL (Zuverlässigkeit, Performance). Docker Compose nimmt viel Arbeit ab, aber Backups bleiben Handarbeit – es sei denn, eigene Skripte laufen.
Sicherheit: n8n bringt keine Benutzerverwaltung. HTTP-Basic-Auth sollte Minimum sein, besser noch ein Reverse-Proxy mit zusätzlicher Authentifizierung. Standardpasswörter sind keine Option, offene Ports sowieso nicht.
Was bedeutet das konkret für Agenturen, Entwickler, Selbstständige?
Agenturen mit mehreren Projekten profitieren von Docker – sauber getrennte Instanzen, schneller Umzug, wenige Konflikte. Entwickler sparen Zeit beim Aufsetzen und Updaten. Aber: Backups und Staging müssen ernst genommen werden. Sonst rächt sich der Komfort beim ersten Fehler.
Selbstständige können mit wenig Aufwand eine solide Automatisierung aufbauen. Aber auch hier: Sicherheitsstandards beachten. Standardpasswörter und offene Ports sind Einladungen für Ärger.
Automatisierte Backups und Update-Prozesse kosten anfangs ein paar Stunden, sparen später aber richtig Zeit. Monitoring über Watchtower oder eigene Skripte hilft, Ausfälle früh zu erkennen.
Mehr aus der Serie
- Teil 2: n8n mit Docker installieren
- Teil 3: Erste n8n-Workflows
- Teil 8: Fehlerbehandlung in n8n
Fazit
Docker und Compose sind für n8n inzwischen Standard – jedenfalls überall dort, wo Zuverlässigkeit zählt. Ohne Backups und getestete Updates bleibt das System anfällig. Wer regelmäßig sichert und vor Updates testet, hat wenig zu befürchten. Wer das nicht tut, kennt das Gefühl, wenn plötzlich alles stillsteht. Muss man nicht haben.
PostgreSQL als Datenbank, persistente Volumes, automatisierte Backups – das sind keine Extras, sondern Pflicht. Wer das beherzigt, hat mit n8n in Docker kaum noch schlaflose Nächte.
bye
mo
Zuletzt bearbeitet: