n8n updaten: Schritt für Schritt ohne kaputte Workflows

Q: Muss ich für ein Update meine Workflows anhalten?

Der Container ist während `down`/`up` kurz weg – laufende Ausführungen brechen ab, und Webhooks laufen in dieser Zeit ins Leere. Bei SQLite solltest du n8n vorher ohnehin stoppen, um den Ordner sauber zu sichern. Leg das Update in eine ruhige Zeit.

Techniker arbeitet im Halbdunkel an Serverhardware – n8n-Update auf dem eigenen Server

Ein n8n-Update ist in zwei Minuten durch – docker compose pull, down, up -d, fertig. Das Problem ist nicht das Update. Das Problem ist der Fall, in dem danach etwas nicht mehr läuft und du keinen Weg zurück hast. Diese Anleitung zeigt dir den Ablauf, der beides abdeckt: das Update selbst und den Ausweg, falls es schiefgeht. Für n8n Cloud genauso wie für den eigenen Server.

Das Wichtigste auf einen Blick

Regelmäßig updaten – n8n empfiehlt mindestens einmal im Monat, sonst sammeln sich riskante Versionssprünge an

Vollständiges Backup heißt: der .n8n-Ordner mit Verschlüsselungs-Key plus externe Datenbank – ein CLI-Export allein reicht nicht

Ohne den Encryption Key lassen sich deine Zugangsdaten aus keinem Backup wiederherstellen

Version pinnen statt :latest – nur so ist ein Rollback überhaupt möglich

Cloud-Nutzer: Version, Release-Track und Update-Rhythmus stellst du unter Manage → Workspace ein

Vor großen Sprüngen: Breaking Changes lesen – bei 3.0 im Oktober besonders

n8n Cloud: drei Einstellungen, die du kennen solltest

Wenn du n8n Cloud nutzt, musst du nichts pullen und nichts sichern – aber du entscheidest, wann Updates kommen. Die Einstellungen findest du unter Manage → Workspace im Bereich Updates & maintenance; ändern darf sie nur der Instanz-Owner. Ein Versionswechsel löst einen Neustart von ein bis zwei Minuten aus.

Einstellung	Was sie macht	Meine Empfehlung
n8n version	setzt die laufende Version direkt	Vor dem Wechsel „Open changelog” anklicken
Release track	Beta = sofort, Stable = später und erprobter	Stable, sobald Kunden dranhängen
Update cadence	Security & stability (ca. alle 2 Wochen) oder jedes neue Release	Security & stability für die meisten

Sicherheits- und Stabilitätsupdates spielt n8n unabhängig von deiner Wahl immer automatisch ein.

Self-hosted: zuerst das Backup – und zwar ein vollständiges

Hier liegt der häufigste Fehler. Viele exportieren ihre Workflows und halten das für ein Backup. Ist es nicht. Ein vollständiges Backup einer selbst gehosteten Instanz besteht laut n8n aus zwei Teilen:

1. Der .n8n-Ordner (standardmäßig ~/.n8n). Darin liegt die config-Datei mit dem Verschlüsselungs-Key – und bei der Standard-Datenbank SQLite auch die Datenbank selbst. Wenn Binär- oder Ausführungsdaten im Modus filesystem liegen, stecken auch die dort drin. In Docker liegt dieser Ordner im Volume n8n_data, gemountet auf /home/node/.n8n.

2. Deine externe Datenbank, falls du PostgreSQL statt SQLite nutzt – gesichert mit den Bordmitteln der Datenbank.

Der Punkt, an dem Backups wertlos werden: n8n speichert Zugangsdaten verschlüsselt. Ohne den Encryption Key aus der config-Datei – oder einen selbst gesetzten N8N_ENCRYPTION_KEY – lässt sich eine wiederhergestellte Datenbank nicht entschlüsseln. Sicher also niemals nur die Datenbank.

Bei SQLite gilt außerdem: n8n stoppen, bevor du den Ordner kopierst. Eine Kopie während laufender Schreibzugriffe kann inkonsistent sein.

Und wenn du eigene Nodes über N8N_CUSTOM_EXTENSIONS lädst oder Binärdaten in S3 beziehungsweise Azure liegen – beides gehört ebenfalls ins Backup.

Der CLI-Export als Ergänzung

Zusätzlich lohnt sich ein lesbarer Export von Workflows und Zugangsdaten:

n8n export:workflow --backup --output=backups/workflows/
n8n export:credentials --backup --output=backups/credentials/

Das Flag --backup entspricht --all --pretty --separate – jeder Workflow landet als eigene, lesbare JSON-Datei. Nutz getrennte Zielordner: Der Import von Zugangsdaten mit --separate scheitert derzeit, wenn im selben Ordner auch Workflow-Dateien liegen.

Wichtig zu wissen, was dieser Export nicht enthält: keine Benutzer und Rollen, keine Ausführungshistorie, keine Variablen, keine Instanz-Einstellungen – und nicht den Encryption Key. Damit verschiebst du Workflows zwischen Instanzen. Eine komplette Instanz rettest du damit nicht.

In Docker noch ein Stolperstein: Ein backups/-Verzeichnis im Container überlebt das Neubauen nicht, weil nur der .n8n-Ordner im Volume liegt. Mounte ein Host-Verzeichnis oder kopier die Dateien aus dem Container heraus.

Das Update per Docker Compose

Serverschrank mit blauen und roten Netzwerkkabeln – Rollback-Weg nach einem n8n-Update

Steht das Backup, ist das eigentliche Update kurz:

# In das Verzeichnis mit der Compose-Datei wechseln
cd /pfad/zu/deiner/compose-datei

# Neues Image holen
docker compose pull

# Alte Version stoppen und entfernen
docker compose down

# Neu starten
docker compose up -d

Danach: Logs anschauen (docker compose logs -f), einen Workflow manuell auslösen, und prüfen, ob die Trigger wieder greifen.

Ohne Compose, mit einzelnem Container, läuft es analog: docker pull n8nio/n8n, dann Container stoppen, entfernen und mit denselben Optionen neu starten.

Version pinnen statt `:latest`

Das ist der Unterschied zwischen „ich kann zurück” und „ich hoffe, es geht gut”. In deiner Compose-Datei:

services:
  n8n:
    # statt: image: n8nio/n8n:latest
    image: n8nio/n8n:2.40.3   # konkrete Version eintragen

Drei Gründe dafür:

Rollback wird möglich. Du weißt, auf welche Version du zurückkannst – bei :latest weißt du nach dem Pull nicht mehr, was vorher lief.
Keine Überraschungen bei Neustarts. Ein Container-Neustart zieht dir nicht ungefragt eine neue Version.
Du updatest bewusst. Versionsnummer ändern, Changelog lesen, upgraden.

Wenn’s schiefgeht: der Rollback

Der Weg zurück, in dieser Reihenfolge:

Container stoppen: docker compose down
Alte Versionsnummer in der Compose-Datei eintragen.
Datenbank zurückspielen – und zwar wirklich. Das ist der Schritt, den alle überspringen wollen: n8n migriert Datenbanken nur vorwärts. Eine von 3.0 migrierte Datenbank kann eine ältere n8n-Version nicht mehr lesen. Ohne den eingespielten Backup-Stand startet die alte Version nicht sauber.
.n8n-Ordner aus dem Backup zurücklegen, inklusive config mit dem Encryption Key.
Starten und Logs prüfen.

Genau deshalb steht das Backup in dieser Anleitung vor dem Update und nicht daneben: Ohne Datenbank-Backup gibt es keinen echten Rollback, nur ein Vorwärtsreparieren unter Zeitdruck.

Der Rhythmus, der Ärger erspart

n8n empfiehlt, mindestens einmal im Monat zu updaten – aus einem sehr praktischen Grund: Wer ein Jahr lang nicht updatet, macht irgendwann einen Sprung über mehrere Major-Versionen, und dann treffen alle Breaking Changes auf einmal zu.

Mein Ablauf für produktive Instanzen:

Wann	Was
Monatlich, fixer Termin	Release Notes lesen, Backup, Update, kurzer Funktionstest
Vor Major-Versionen	Breaking Changes durchgehen, betroffene Workflows vorher anpassen
Nie	am Releasetag einer Major-Version upgraden
Bei kritischen Setups	Testinstanz mit derselben Version, dort zuerst upgraden

Für die nächste große Runde heißt das konkret: n8n 3.0 kommt im Oktober 2026 und entfernt über 25 Nodes, macht Docker für Self-Hosting zur Pflicht und ändert mehrere Defaults. Das ist kein Update, das du nebenbei am Freitagabend einspielst.

Und wenn du nach dem Update merken willst, dass etwas klemmt – statt es vom Kunden zu erfahren: Dafür brauchst du Fehlerbehandlung und Monitoring in deinen n8n-Automationen.

Häufige Fragen zum n8n-Update

Wie oft sollte ich n8n updaten? n8n empfiehlt mindestens einmal im Monat. So bleiben die Sprünge klein und jedes Update überschaubar.

Reicht es, meine Workflows zu exportieren? Nein. Der CLI-Export enthält Workflows und Zugangsdaten, aber keine Benutzer, keine Variablen, keine Ausführungshistorie und nicht den Verschlüsselungs-Key. Für eine echte Wiederherstellung brauchst du den .n8n-Ordner und – bei PostgreSQL – die Datenbank.

Kann ich einfach auf eine ältere Version zurück? Nur mit Datenbank-Backup. n8n migriert Datenbanken ausschließlich vorwärts; eine ältere Version kann eine bereits migrierte Datenbank nicht mehr lesen.

Muss ich für ein Update meine Workflows anhalten? Der Container ist während down/up kurz weg – laufende Ausführungen brechen ab, und Webhooks laufen in dieser Zeit ins Leere. Bei SQLite solltest du n8n vorher ohnehin stoppen, um den Ordner sauber zu sichern. Leg das Update in eine ruhige Zeit.

Was ist der Unterschied zwischen Beta und Stable in der Cloud? Beta bekommt neue Releases sofort, Stable einen später gezogenen, erprobteren Patch desselben Releases. Für alles, woran Kunden hängen, empfiehlt n8n Stable.

Wie finde ich heraus, was sich in einer Version geändert hat? Über die Release Notes im n8n-Changelog – in der Cloud direkt per „Open changelog” neben der Versionsauswahl.

Fazit: Das Backup ist das Update

Der eigentliche Update-Befehl ist ein Dreizeiler. Alles, was ein Update riskant oder harmlos macht, passiert davor: ein vollständiges Backup inklusive Encryption Key, eine gepinnte Version, ein gelesener Changelog.

Wenn du diese drei Dinge hast, ist ein n8n-Update eine Routine von zehn Minuten im Monat. Wenn nicht, ist es jedes Mal ein kleines Glücksspiel – und irgendwann verlierst du es an einem Tag, an dem du gerade keine Zeit dafür hast.

Quellen

n8n Docs: Update n8n – abgerufen 2026-09-20
n8n Docs: Back up and restore – abgerufen 2026-09-20
n8n Docs: Install with Docker – abgerufen 2026-09-20
n8n Docs: Update your Cloud version – abgerufen 2026-09-20
n8n Docs: v3.0 Breaking changes – abgerufen 2026-09-20

Über den Autor

Ich bin Chris Schweigler, Automatisierungs-Experte aus Österreich. Ich betreue n8n-Instanzen für selbstständige Onlineunternehmer – vom Setup über Updates bis zum Monitoring. Du willst dein Update nicht selbst durchziehen? Schreib mir.