n8n aktualisieren: Backup, Compose-Update und sicherer Rückweg

Was du vor einem n8n-Update festhältst

Dieser Guide behandelt eine bestehende selbst gehostete Docker-Compose-Installation. n8n Cloud, npm-Installationen, Queue- und Multi-Main-Aufbauten haben andere Abläufe. Änderungen an Betriebssystem, Datenbankmajorversion oder einem neuen Assistant-Sandbox-Stack gehören in eigene Migrationspläne.

Notiere Ist-Version, gewünschte Zielversion, Compose-Projekt, Dienste und Speicherorte. Lies die Releasehinweise und Breaking Changes für den tatsächlich übersprungenen Bereich. Übernimm nicht pauschal latest oder eine Beta. Eine heute genannte Versionsnummer wäre ohnehin kein dauerhafter Updateplan.

docker compose version
docker compose config --services
docker compose images
docker compose ps
docker compose exec n8n n8n --version

Der letzte Befehl setzt voraus, dass der laufende Dienst tatsächlich n8n heißt. Prüfe die Dienste zuerst und passe Namen bewusst an. Die kurze Dienstliste zeigt keine vollständig aufgelöste Konfiguration; damit musst du für diese Inventur keine Zugangswerte ausgeben.

n8n mit Docker und persistentem Speicher betreiben erklärt den grundlegenden Core-Aufbau. Die aktuelle neue Compose-Anleitung mit Assistant-Komponenten ist ein separater Installationsumfang; ein Bestandsupdate verlangt nicht automatisch dessen Nachrüstung.

Ein Workflow-Export ist noch kein Vollbackup

Die offizielle Backup-Anleitung unterscheidet zwischen Workflow-/Credential-Export und vollständiger Instanzsicherung. Selbst das Server-CLI-Flag --backup exportiert nicht alles: Nutzer, Rollen, Verlauf, Variablen, Einstellungen und Verschlüsselungsschlüssel sind damit nicht vollständig gesichert.

Bei SQLite hältst du n8n vor einer einfachen Dateikopie an oder verwendest ein geeignetes konsistentes Snapshotverfahren. Eine während Schreibzugriffen kopierte Datenbank kann unbrauchbar sein. Auch bei externen Datenbanken brauchst du einen abgestimmten konsistenten Sicherungszeitpunkt.

Ein passender Schlüssel ist nötig, um verschlüsselte Zugangsdaten wieder zu verwenden. Lagere die Sicherung geschützt und getrennt vom Webzugriff. Datenwege und Speicher in n8n prüfen hilft dir, zusätzliche Ausführungs- und Inhaltsdaten im eigenen Aufbau zu finden. Ein hier angebotener öffentlicher Download enthält ausdrücklich keine echten Instanzdaten.

Zielversion in einer getrennten Testumgebung prüfen

Lade das leere eigene Wartungsblatt herunter. Trage Versionen, Sicherungszeitpunkt, Speicherorte und Prüffälle ein. Zugangsdaten selbst gehören nicht in dieses Arbeitsblatt.

Stelle die Sicherung in einer isolierten Umgebung wieder her. Verhindere dabei, dass kopierte Zeitpläne, Webhooks oder ausgehende Nodes echte Nachrichten und andere Aktionen erneut auslösen. Plane dieses Isolieren vor dem ersten Start: Ein Start zur Prüfung kann sonst bereits Effekte haben.

Teste dort die gewählte Zielversion und die benötigten Nodes. Prüfe eigene Code-Nodes, Community-Nodes, Authentisierungen und relevante API-Verbindungen mit dafür vorgesehenen Testzugängen. Externe Task Runner müssen zur n8n-Version passen; Queue-Worker brauchen ihre eigene passende Runnerzuordnung.

Ist-Version: ...
Geprüfte Zielversion: ...
Vollbackup und Restoreprobe: ...
Drei repräsentative Prüffälle: ...
Ausgehende Testaktionen begrenzt: ...
Verantwortliche Person und Rückweg: ...

Erst ein tatsächlich gelungener Restore zeigt, dass Sicherung, Schlüssel und Konfiguration zusammen verwendbar sind. Dieses Arbeitsblatt ist unbefüllt; es behauptet keinen erfolgreichen Wiederherstellungstest.

Ein bestehendes Compose-Setup aktualisieren

Plane ein Wartungsfenster und verhindere neue fachliche Aufträge während des Eingriffs. Nach abgeschlossener Sicherung und Testfreigabe änderst du in deiner bestehenden Konfiguration das App-Image auf die geprüfte feste Version. Lasse Projektname, Datenvolumes und Datenbankzuordnung bewusst erhalten.

Bei externen Task Runners setzt du deren Image auf die zur App passende Version. Die folgenden Befehle gelten nur für ein zuvor geprüftes einfaches Setup, dessen Dienste genau n8n und task-runners heißen. Beide Images müssen bereits richtig gepinnt sein. Worker, weitere Appinstanzen und zusätzliche Dienste erfordern ihren eigenen abgestimmten Ablauf.

docker compose pull n8n task-runners
docker compose up -d --no-deps n8n task-runners
docker compose ps
docker compose exec n8n n8n --version

pull lädt die in deiner Konfiguration festgelegten Images. up erstellt die betroffenen Dienste bei Bedarf neu. --no-deps lässt Abhängigkeitsdienste hier bewusst unangetastet. Falls dein abgegrenzter Core-Lernaufbau keinen externen Runnerdienst enthält, beziehst du die Dienstbefehle nur auf n8n; das ist keine Empfehlung, produktive Codeausführung ohne externe Isolation zu betreiben.

Dieser Ablauf führt kein Datenbankmajorupgrade aus und entfernt keine Volumes. Ein leerer Editor nach dem Start ist ein Grund, Mounts, Projektname und Datenbankziel zu prüfen. Richte nicht vorschnell eine vermeintlich neue Instanz ein.

Nach dem Start gezielt abnehmen

1. Prüfe gestartete Dienste, tatsächliche Appversion und sichtbare Fehlermeldungen. Kontrolliere insbesondere Datenbankzugriff und Runnerstatus.
2. Melde dich im richtigen Editor an. Sind erwartete Nutzer, Workflows und Einstellungen vorhanden?
3. Prüfe ausgewählte gespeicherte Zugänge mit kontrollierten Testoperationen. Verschlüsselte n8n-Zugangsdaten einordnen erklärt, weshalb ein fehlender Schlüssel trotz vorhandener Datenbank relevant ist.
4. Führe die vorher festgelegten manuellen Prüffälle aus und vergleiche Daten und erlaubte Effekte.
5. Gib Zeitpläne und produktive Eingänge erst nach der fachlichen Abnahme wieder frei. Beobachte die ersten echten Ausführungen und dokumentiere offene Fehler.

Ein erreichbarer Editor allein beweist weder vollständige Datenwiederherstellung noch funktionierende Integrationen. Logs können Inhalte enthalten: Teile zur Fehlersuche gezielt bereinigte Ausschnitte statt kompletter privater Konfigurationen.

Wenn das Update scheitert: vollständig zurückkehren

Notiere zuerst den Fehler und halte neue Ausführungen an. Verhindere, dass weitere Aktionen auf einem unklaren Stand stattfinden. Eine erneute identische Ausführung kann externe Effekte verdoppeln.

Falls die neue Version bereits Datenbankmigrationen ausgeführt hat, ist ein altes Image auf dem neuen Datenstand kein allgemein sicherer Downgrade. Dein Rückweg muss die passende alte Anwendung und den dazugehörigen konsistenten Datenstand einschließlich Schlüssel, Konfiguration und Zusatzspeicher wieder zusammenbringen.

Die offizielle Restorefolge beginnt mit angehaltenem n8n, Wiederherstellung der Instanzdateien und gegebenenfalls PostgreSQL, anschließend der passenden Deploymentkonfiguration und erst dann dem Start. Prüfe diesen Weg vorher isoliert. Bereits versendete Nachrichten oder andere externe Effekte werden durch ein Instanzrestore nicht automatisch zurückgenommen.

Für diesen Artikel wurden Dokumentation und eigene Prüfkriterien ausgearbeitet. Auf keiner realen n8n-Instanz wurden ein Imagewechsel, eine Migration oder ein Restore ausgeführt. Das Wartungsblatt hilft dir, den tatsächlich erreichten Stand später sauber zu dokumentieren.

n8n 3.0 vorbereiten: angekündigt, noch nicht stabil verfügbar

Stand 26. Oktober 2026: n8n hat Version 3.0 am 23. Oktober angekündigt. Die Beta ist für den 27. Oktober geplant, die stabile 3.x-Ausgabe für Anfang Dezember. Das sind angekündigte Termine. Dieser Guide behauptet weder eine bereits veröffentlichte stabile Version noch eine auf deiner Instanz bestandene Migration.

Für einen bestehenden Betrieb ist zuerst der Migration Report unter Settings → Migration Report sinnvoll. Er ist ab Version 2.39 verfügbar; laut Ankündigung enthält die jeweils aktuelle 2.x-Version den neuesten Report. Er zeigt betroffene Workflows und Instanzeinstellungen. Automatische Korrekturen erzeugen eine neue Workflowversion, die du anschließend prüfen und veröffentlichen musst.

Die vollständige Liste enthält weitere Änderungen, etwa Binärspeicherpfade, Task-Runner-Timeouts und Ausgabeverhalten mehrerer Zweige. Nutze den Report für deine konkrete Instanz und die verlinkten Breaking Changes für die Details. Eine kurze Tabelle kann diese Prüfung nicht vollständig ersetzen.

Wenn du noch auf 1.x bist, nennt n8n den Weg zuerst auf 2.x und danach auf 3.x. Für 2.x sind Sicherheits- und kritische Fehlerkorrekturen bis zwölf Monate nach der stabilen3.x-Veröffentlichung angekündigt. Das ist ein Plan des Herstellers, kein Grund, eine ungeprüfte Beta auf den Produktivdaten zu starten.

Oktober 2026: Diese Änderungen gezielt abnehmen

Für die Abnahme zählen hier Modellangaben in KI-Logs, die Veröffentlichung von Workflowtools und optionale Classifier-Scores. Prüfe diese Änderungen an den tatsächlich verwendeten Abläufen. Release: 20. Oktober 2026 · Quellen geprüft: 26. Oktober 2026. Die Notizen zu n8n 2.45 nennen neue Kontrollen für KI-Abläufe. Eine Release-Nummer garantiert nicht, dass jedes Feature in deinem Konto verfügbar ist: Rollout, Betriebsart und aktivierte Funktionen gehören in dein Wartungsblatt.

Für einen MCP-bezogenen Test muss außerdem klar sein, wer den Aufruf auslöst: ein fester Workflow-Schritt oder ein Agent. Damit kannst du die n8n-MCP-Verbindung gezielt prüfen, ohne Probleme im Ablauf mit Problemen bei der Werkzeugwahl zu verwechseln.

Eine weitere wichtige Trennung betrifft Gemini: Der n8n-Beitrag vom 13. Oktober beschreibt den externen Workflow-Builder, den Assistant und das Modell im ausgeführten Workflow als unterschiedliche Einsatzwege. Halte deshalb fest, welche Ebene du aktualisierst. Ein Modell im Bauwerkzeug legt das Laufzeitmodell des fertigen Workflows nicht automatisch fest.

Oktober-Abnahmeblatt als CSV herunterladen. Trage Ist- und Zielversion, Featureverfügbarkeit, Beobachtung und Abnahmeentscheidung selbst ein. Es enthält keine echten Instanzdaten und keine bereits bestandenen Prüfungen.