Workflow-Versionierung: Change History, JSON-Export, Git-Backup-Workaround für Community Edition

Wer in n8n Workflows baut, verändert sie ständig: ein Node wird ergänzt, ein Filter angepasst, eine Fehlerbehandlung nachgerüstet. Ohne Versionierung ist jede dieser Änderungen ein stiller Überschreibvorgang, und die Frage "Welche Version lief gestern noch stabil?" lässt sich nicht mehr beantworten. n8n bringt dafür eine eingebaute Change History mit, aber die volle Historie und der native Git-Abgleich über Source Control sind den Business- und Enterprise-Plänen vorbehalten, nicht der kostenlosen Community Edition.

Für alle anderen bleibt der manuelle JSON-Export als Workaround: Workflows lassen sich jederzeit als JSON-Datei herunterladen und in ein eigenes Git-Repository einchecken. Dieser Artikel zeigt, was die eingebaute Change History wirklich leistet, wo ihre Grenzen liegen und wie Du Dir mit Bordmitteln ein funktionierendes Backup- und Versionierungssystem baust, auch ohne Enterprise-Lizenz.

Was zeigt die eingebaute Workflow-Change-History?

Jeder Workflow in n8n hat ein eigenes Verlaufssymbol, über das Du ein Menü mit allen gespeicherten Versionen öffnest, jeweils mit einer Canvas-Vorschau der ausgewählten Version. Laut n8n-Dokumentation zur Change History legt n8n automatisch eine neue Version an, wenn Du den Workflow speicherst, eine alte Version wiederherstellst (die zuvor aktive Version wird dabei zuerst gesichert) oder per Source Control aus einem Git-Repository pullst.

Zu jeder gespeicherten Version stehen Dir mehrere Aktionen zur Verfügung:

• Version wiederherstellen: ersetzt den aktuellen Workflow durch die ausgewählte Version.
• In neuen Workflow klonen: legt eine Kopie der Version als eigenständigen Workflow an.
• Version in neuem Tab öffnen: ermöglicht den direkten Vergleich zweier Versionen nebeneinander.
• Herunterladen: exportiert die gewählte Version als JSON-Datei.
• Version benennen: schützt sie vor automatischer Bereinigung, dieses Feature ist Pro- und Enterprise-Nutzern vorbehalten.

Wichtig für die Praxis ist die Reichweite dieser Historie. Sie unterscheidet sich deutlich je nach Plan:

• Enterprise (Cloud oder Self-hosted): volle Workflow-History ohne zeitliche Begrenzung.
• Cloud Pro: Versionen der letzten fünf Tage.
• Alle übrigen Nutzer, inklusive Community Edition: nur Versionen der letzten 24 Stunden.

Das heißt konkret: Wer die Community Edition oder einen einfachen Cloud-Plan nutzt, verliert nach spätestens einem Tag den Zugriff auf ältere Zwischenstände. Für eine echte, dauerhafte Versionshistorie reicht die eingebaute Funktion in diesen Fällen nicht aus.

Warum ist Source Control per Git nicht für jeden verfügbar?

n8n bietet mit Source Control eine native Git-Integration, mit der sich Workflows automatisch mit einem Repository synchronisieren lassen, inklusive mehrerer Umgebungen über getrennte Git-Branches. Laut n8n-Dokumentation zu Source Control und Environments ist diese Funktion jedoch "Available on Business and Enterprise plans", also nicht Teil der kostenlosen Community Edition und auch nicht der einfachen Cloud-Tarife.

Wo Source Control verfügbar ist, läuft die Einrichtung über Settings > Environments. Du hinterlegst dort die Git-Repository-URL, entweder per SSH mit einem Deploy Key oder per HTTPS mit einem Personal Access Token, und n8n generiert dafür automatisch einen SSH-Schlüssel (standardmäßig ED25519). Instanz-Owner und Instanz-Admins dürfen anschließend sowohl pushen als auch pullen, Projekt-Admins nur pushen. Wer produktiv mit mehreren Umgebungen arbeitet und die Business- oder Enterprise-Lizenz besitzt, sollte diesen nativen Weg nutzen, er nimmt einem die manuelle Pflege des Exports ab.

Der Workaround: manuelles Git-Backup per JSON-Export

Ohne Business- oder Enterprise-Lizenz bleibt der JSON-Export der zuverlässigste Weg, Workflows dauerhaft und versioniert zu sichern. Laut n8n-Dokumentation zu Export und Import speichert n8n Workflows grundsätzlich im JSON-Format, und genau dieses Format lässt sich exportieren, in ein Git-Repository einchecken und dort wie jede andere Codeänderung committen, taggen und zurückrollen.

Export über die Oberfläche

Für einzelne Workflows reicht die Editor-Oberfläche völlig aus:

• Öffne den Workflow und klicke auf das Drei-Punkte-Menü oben rechts.
• Wähle Download, um den aktuellen Workflow als JSON-Datei auf Deinen Rechner zu laden.
• Alternativ kannst Du einzelne Nodes markieren, mit Strg+C beziehungsweise Cmd+C kopieren und in einen Texteditor einfügen, das ergibt ebenfalls valides Workflow-JSON für Teilbereiche.
• Über Import from File oder Import from URL lässt sich eine JSON-Datei später wieder in n8n zurückladen.

Die Dokumentation weist ausdrücklich darauf hin, dass exportierte JSON-Dateien Credential-Namen und Credential-IDs enthalten. Bevor Du eine solche Datei teilst oder in ein gemeinsames Repository legst, solltest Du diese Angaben entfernen oder anonymisieren, damit keine sensiblen Zugangsdaten versehentlich in der Versionshistorie landen.

Export über die Kommandozeile für ganze Instanzen

Für ein vollständiges Backup aller Workflows einer selbst gehosteten n8n-Instanz eignet sich die CLI besser als der manuelle Einzel-Download. Laut n8n-Dokumentation zur Kommandozeile stehen dafür eigene Export- und Import-Befehle bereit:

• `n8n export:workflow --all --output=backups/latest/` exportiert alle Workflows in ein Verzeichnis.
• `n8n export:workflow --backup --output=backups/latest/` nutzt den dedizierten Backup-Modus, der intern `--all --pretty --separate` setzt: alle Workflows, lesbar formatiert, jeweils als eigene Datei.
• `n8n export:workflow --id=<ID> --output=file.json` exportiert gezielt einen einzelnen Workflow.
• `n8n import:workflow --separate --input=backups/latest/` importiert ein komplettes Verzeichnis mit einzelnen JSON-Dateien zurück.
• `n8n import:workflow --separate --input=backups/latest/ --activeState=fromJson` übernimmt beim Import auch den ursprünglichen Aktivierungsstatus jedes Workflows.

So baust Du daraus ein Git-Backup

Kombiniere den Backup-Modus der CLI mit einem regelmäßigen Cron-Job und einem Git-Repository, dann hast Du im Ergebnis eine selbst gebaute, aber solide Versionierung:

1. Lege ein privates Git-Repository an, getrennt von Deinem sonstigen Anwendungscode.

2. Richte einen täglichen Cron-Job auf dem n8n-Server ein, der `n8n export:workflow --backup --output=backups/latest/` ausführt.

3. Committe die exportierten Dateien automatisiert oder manuell in das Repository, mit einer aussagekräftigen Commit-Message.

4. Prüfe vor jedem Commit, dass keine unbereinigten Credential-Referenzen enthalten sind, idealerweise über ein einfaches Skript, das bekannte Muster wie `credentialId` herausfiltert oder markiert.

5. Nutze bei Bedarf `git tag`, um stabile Produktionsstände klar zu markieren, so findest Du sie auch Monate später wieder.

Damit erreichst Du im Kern das, was Source Control nativ bietet, nur ohne automatischen Push-Pull-Mechanismus und mit etwas mehr Handarbeit beim Zurückspielen. Für kleinere Teams und einzelne Freelancer ist das oft ein vertretbarer Kompromiss, bevor sich eine Business-Lizenz wirtschaftlich lohnt.

Wie lange bewahrt n8n Versionen automatisch auf?

Wer die eingebaute Workflow-History nutzt und die Speicherdauer selbst steuern will, findet die passende Stellschraube in der Server-Konfiguration. Laut n8n-Dokumentation zu den Umgebungsvariablen der Workflow-History legt die Variable `N8N_WORKFLOW_HISTORY_PRUNE_TIME` fest, wie viele Stunden alte Versionen aufbewahrt werden, bevor n8n sie automatisch löscht. Der Standardwert ist `-1`, was bedeutet, dass technisch alle Versionen unbegrenzt aufgehoben werden, allerdings greifen für die Sichtbarkeit weiterhin die plan-abhängigen Grenzen aus dem vorherigen Abschnitt.

Bei selbst gehosteten Instanzen ohne Enterprise-Lizenz lohnt es sich trotzdem, diese Variable bewusst zu setzen und zusätzlich den JSON-Export-Workaround zu etablieren. So behältst Du die Kontrolle über Deine Versionshistorie, unabhängig davon, was die Oberfläche gerade anzeigt oder ausblendet.

Häufige Fragen

Brauche ich zwingend eine Enterprise-Lizenz für Workflow-Versionierung?

Nein. Die eingebaute Change History mit voller Historie und die native Git-Synchronisation über Source Control sind zwar den Business- und Enterprise-Plänen vorbehalten, aber der manuelle JSON-Export funktioniert in jeder n8n-Version, auch in der kostenlosen Community Edition. Kombiniert mit einem eigenen Git-Repository und einem regelmäßigen CLI-Export erreichst Du eine vollwertige, wenn auch manuelle Versionierung.

Wie lange speichert n8n Workflow-Versionen ohne Business- oder Enterprise-Plan?

In der Community Edition und in einfachen Plänen sind nur Versionen der letzten 24 Stunden über die Oberfläche einsehbar, selbst wenn die Umgebungsvariable `N8N_WORKFLOW_HISTORY_PRUNE_TIME` auf unbegrenzte Aufbewahrung steht. Für alles, was länger zurückliegen soll, brauchst Du entweder einen höheren Plan oder Dein eigenes Backup-System per JSON-Export.

Enthalten exportierte JSON-Dateien meine Zugangsdaten?

Exportierte Workflow-JSON-Dateien enthalten laut n8n-Dokumentation Credential-Namen und Credential-IDs, aber keine Klartext-Passwörter oder Tokens. Trotzdem solltest Du diese Referenzen vor dem Teilen oder vor dem Einchecken in ein gemeinsames Repository entfernen oder anonymisieren, damit niemand aus den IDs Rückschlüsse auf Deine Zugangsdaten-Struktur ziehen kann.

Kann ich einzelne Nodes statt des ganzen Workflows sichern?

Ja. Markierst Du einzelne Nodes im Canvas und kopierst sie mit Strg+C beziehungsweise Cmd+C, erhältst Du ebenfalls gültiges Workflow-JSON, das sich in einem Texteditor speichern und später wieder einfügen lässt. Das eignet sich gut, um wiederverwendbare Bausteine wie eine Fehlerbehandlung oder eine Standard-HTTP-Konfiguration separat zu versionieren.

Was ist der Unterschied zwischen der CLI-Backup-Option und einem einfachen Export aller Workflows?

Der Befehl `n8n export:workflow --backup` setzt automatisch die Flags `--all --pretty --separate`, exportiert also alle Workflows der Instanz, formatiert das JSON lesbar und legt für jeden Workflow eine eigene Datei an. Ein einfacher Export mit `--all` ohne diese Flags kann dagegen alle Workflows in eine einzige Datei oder unformatiert schreiben, was den späteren Diff-Vergleich in Git deutlich unübersichtlicher macht. Für ein sauberes Git-Backup ist der Backup-Modus daher die bessere Wahl.