Wichtige Änderungen in n8n v2.0 | n8n Dokumentation

n8n v2.0 wird in Kürze veröffentlicht. Dieses Dokument hebt die wichtigsten Breaking Changes hervor und erklärt, welche Vorbereitungen du für den Übergang treffen solltest. Diese Updates verbessern die Sicherheit, vereinfachen die Konfiguration und entfernen veraltete Funktionen.

Mit n8n 2.0 setzt n8n sein Ziel fort, eine sichere, zuverlässige und produktionsreife Automatisierungsplattform bereitzustellen. Diese Hauptversion enthält wichtige Sicherheitsverbesserungen und entfernt veraltete bzw. eingestellte Funktionen.

Verhaltensänderungen

Erwartete Daten zurückgeben, wenn ein Sub-Workflow aus dem Wartezustand fortgesetzt wird

Bisher erhielt eine Parent-Ausführung (Parent) ein falsches Ergebnis, wenn sie eine Child-Ausführung (Child) aufrief, die einen Knoten enthielt, der die Child-Ausführung in einen Wartezustand versetzte, und wenn die Parent-Ausführung so konfiguriert war, dass sie auf den Abschluss der Child-Ausführung wartet.

Dies geschieht zum Beispiel, wenn die Child-Ausführung einen Wait-Knoten mit einer Timeout-Zeit von mehr als 65 Sekunden, einen Webhook-Aufruf, eine Formularübermittlung oder einen Human-in-the-loop-Knoten enthält, etwa einen Slack-Knoten.

Übergeordneter Workflow:

Untergeordneter Workflow:

v1: Die Parent-Ausführung gibt die Eingabe der Child-Ausführung als Ausgabe wieder:

v2: Die Parent-Ausführung erhält das Ergebnis der Child-Ausführung:

Dadurch ist es möglich, in einem Sub-Workflow Human-in-the-loop-Knoten zu verwenden und das Ergebnis dieser Freigaben im übergeordneten Workflow zu nutzen, zum Beispiel zum Genehmigen oder Ablehnen einer Aktion.

Migrationspfad: Prüfe alle Workflows, die Sub-Workflows aufrufen und dabei erwarten, die Eingabe des Sub-Workflows zurückzuerhalten. Aktualisiere diese Workflows für das neue Verhalten: Der übergeordnete Workflow erhält jetzt die Ausgabe am Ende des Sub-Workflows statt dessen Eingabe.

Start-Knoten entfernen

Der Start-Knoten wird nicht mehr unterstützt. Dieser Knoten war die ursprüngliche Methode zum Starten eines Workflows und wurde inzwischen durch gezieltere Trigger-Knoten ersetzt.

Migrationspfad: Ersetze den Start-Knoten je nach Verwendung deines Workflows:

• Manuelle Ausführung: Ersetze den Start-Knoten durch den Manual Trigger-Knoten.
• Sub-Workflow: Wenn dieser Workflow von einem anderen Workflow als Sub-Workflow aufgerufen wird, ersetze den Start-Knoten durch den Execute Workflow Trigger-Knoten und aktiviere den Workflow.
• Deaktivierter Start-Knoten: Wenn der Start-Knoten bereits deaktiviert ist, entferne ihn aus dem Workflow.

Workflows speichern und veröffentlichen

Das neue System zum Veröffentlichen von Workflows ersetzt den bisherigen Aktivieren/Deaktivieren-Schalter. Der bisherige Schalter „Aktivieren/Deaktivieren“ wird durch die neue Schaltfläche „Veröffentlichen/Veröffentlichung aufheben“ ersetzt. Diese Änderung gibt dir mehr Kontrolle darüber, wann Änderungen an einem Workflow veröffentlicht werden, und reduziert das Risiko, unfertige Änderungen versehentlich produktiv bereitzustellen. Weitere Informationen findest du unter: Workflows speichern und veröffentlichen.

Knoten für eingestellte externe Dienste entfernen

Die folgenden Knoten wurden entfernt, weil die externen Dienste, mit denen sie verbunden waren, nicht mehr verfügbar sind:

• Spontit-Knoten
• crowd.dev-Knoten
• Kitemaker-Knoten
• Automizy-Knoten

Migrationspfad: Wenn deine Workflows einen der oben genannten Knoten verwenden, aktualisiere oder entferne diese Workflows, um Fehler zu vermeiden.

Sicherheit

Standardmäßig den Zugriff von Code-Knoten auf Umgebungsvariablen blockieren

Zur Verbesserung der Sicherheit blockiert n8n standardmäßig den Zugriff von Code-Knoten auf Umgebungsvariablen. Der Standardwert von N8N_BLOCK_ENV_ACCESS_IN_NODE wird jetzt auf true gesetzt.

Migrationspfad: Wenn deine Workflows Zugriff auf Umgebungsvariablen in Code-Knoten benötigen, setze in deiner Umgebungskonfiguration N8N_BLOCK_ENV_ACCESS_IN_NODE=false. Für sensible Daten empfiehlt es sich, Credentials oder andere sichere Methoden statt Umgebungsvariablen zu verwenden.

Dateiberechtigungen erzwingen

n8n wird strengere Dateiberechtigungen für Konfigurationsdateien verlangen, um die Sicherheit zu erhöhen. Standardmäßig müssen Konfigurationsdateien die Berechtigung 0600 haben, sodass nur der Dateieigentümer sie lesen und schreiben kann. Das entspricht dem Schutzprinzip, das auch SSH für private Schlüssel verwendet.

Migrationspfad: Um dieses Verhalten schon vor v2.0 zu testen, setze N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true. Wenn deine Umgebung keine Dateiberechtigungen unterstützt, zum Beispiel unter Windows, setze N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false, um diese Anforderung zu deaktivieren.

Task Runner standardmäßig aktivieren

n8n aktiviert standardmäßig Task Runner, um Sicherheit und Isolierung zu verbessern. Alle Ausführungen von Code-Knoten laufen dann auf Task Runnern.

Migrationspfad: Setze vor dem Upgrade auf v2.0 N8N_RUNNERS_ENABLED=true, um dieses Verhalten zu testen. Stelle sicher, dass deine Infrastruktur die Anforderungen für den Betrieb von Task Runnern erfüllt. Für zusätzliche Sicherheit kannst du den externen Modus in Betracht ziehen.

Task Runner aus dem Docker-Image n8nio/n8n entfernen

Ab v2.0 enthält das zentrale Docker-Image n8nio/n8n keine Task Runner mehr für den externen Modus. Du musst das separate Docker-Image n8nio/runners verwenden, um Task Runner im externen Modus auszuführen.

Migrationspfad: Wenn du Task Runner im externen Modus mit Docker betreibst, aktualisiere deine Konfiguration so, dass statt n8nio/n8n das Image n8nio/runners verwendet wird.

Auf Pyodide basierenden Python-Code-Knoten und Tools entfernen

n8n entfernt den auf Pyodide basierenden Python-Code-Knoten und die entsprechenden Tools und ersetzt sie durch eine auf Task Runnern basierende Implementierung, die native Python-Ausführung verwendet und bessere Sicherheit sowie höhere Leistung bietet. Ab v2.0 kannst du den Python-Code-Knoten nur noch zusammen mit Task Runnern im externen Modus und nativen Python-Tools verwenden.

Der native Python-Code-Knoten unterstützt weder die in der Pyodide-Version vorhandenen eingebauten Variablen wie _input noch die Punktzugriffsnotation. Weitere Informationen findest du in der Dokumentation zum Code-Knoten.

Native Python-Tools unterstützen _query, also die Eingabezeichenfolge, die ein KI-Agent beim Aufruf eines Tools übergibt.

Migrationspfad: Wenn du Python weiterhin in Code-Knoten verwenden möchtest, richte Task Runner im externen Modus ein und prüfe, ob deine vorhandenen Python-Code-Knoten und Tools kompatibel sind.

ExecuteCommand- und LocalFileTrigger-Knoten standardmäßig deaktivieren

n8n deaktiviert die Knoten ExecuteCommand und LocalFileTrigger standardmäßig, da sie Sicherheitsrisiken darstellen. Diese Knoten ermöglichen es Benutzern, beliebige Befehle auszuführen und auf das Dateisystem zuzugreifen.

Migrationspfad: Wenn du diese Knoten verwenden musst, entferne sie durch Anpassen der Umgebungsvariable NODES_EXCLUDE aus der über NODES_EXCLUDE definierten Ausschlussliste. Setze zum Beispiel NODES_EXCLUDE="[]", um alle Knoten zu aktivieren, oder entferne nur die Knoten, die du tatsächlich benötigst.

Standardmäßig Authentifizierung für OAuth-Callback-Endpunkte verlangen

n8n verlangt standardmäßig eine Authentifizierung für OAuth-Callback-Endpunkte. Der Standardwert von N8N_SKIP_AUTH_ON_OAUTH_CALLBACK ändert sich von true (keine Authentifizierung erforderlich) auf false (Authentifizierung erforderlich).

Migrationspfad: Setze vor dem Upgrade auf v2.0 N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false und teste deine OAuth-Integrationen, um sicherzustellen, dass sie mit aktivierter Authentifizierung korrekt funktionieren.

Standardwert für N8N_RESTRICT_FILE_ACCESS_TO festlegen

n8n legt einen Standardwert für N8N_RESTRICT_FILE_ACCESS_TO fest, um zu steuern, wo Dateivorgänge ausgeführt werden dürfen. Dies betrifft die Knoten ReadWriteFile und ReadBinaryFiles. Standardmäßig können diese Knoten nur auf Dateien im Verzeichnis ~/.n8n-files zugreifen.

Migrationspfad: Prüfe Workflows, die Dateiknoten verwenden, und stelle sicher, dass sie nur auf Dateien in zulässigen Verzeichnissen zugreifen. Wenn weitere Verzeichnisse erlaubt sein sollen, setze die Umgebungsvariable N8N_RESTRICT_FILE_ACCESS_TO auf den gewünschten Pfad.

Standardwert von N8N_GIT_NODE_DISABLE_BARE_REPOS auf true ändern

Aus Sicherheitsgründen blockiert der Git-Knoten Bare-Repositories jetzt standardmäßig. Der Standardwert von N8N_GIT_NODE_DISABLE_BARE_REPOS wird auf true gesetzt. Das bedeutet, dass Bare-Repositories deaktiviert sind, sofern du diese Einstellung nicht änderst.

Migrationspfad: Wenn deine Workflows Bare-Repositories benötigen, setze in deiner Umgebungskonfiguration N8N_GIT_NODE_DISABLE_BARE_REPOS=false, um sie zu aktivieren.

Daten

Support für MySQL/MariaDB beenden

n8n unterstützt MySQL und MariaDB nicht länger als Speicher-Backend; diese Unterstützung wurde bereits in v1.0 als veraltet markiert. Für optimale Kompatibilität und langfristigen Support solltest du PostgreSQL verwenden. Der MySQL-Knoten wird weiterhin wie bisher unterstützt.

Migrationspfad: Migriere deine Daten vor dem Upgrade auf v2.0 mithilfe eines Datenbank-Migrationstools von MySQL oder MariaDB nach PostgreSQL oder SQLite.

Veralteten SQLite-Treiber entfernen

Wegen Zuverlässigkeitsproblemen entfernt n8n den veralteten SQLite-Treiber. Der Treiber mit Verbindungspooling wird zum einzigen SQLite-Treiber. Dieser verwendet den WAL-Modus, eine einzelne Schreibverbindung und einen Lese-Verbindungspool. Unsere Benchmarks zeigen, dass er bis zu 10-mal schneller sein kann.

Migrationspfad: Der Treiber sqlite-pooled wird automatisch zum Standardtreiber. Du kannst Verbindungspooling sofort aktivieren, indem du DB_SQLITE_POOL_SIZE auf einen Wert größer als 0 setzt. Die Standardgröße des Verbindungspools wird auf 2 gesetzt.

In-Memory-Modus für Binärdaten entfernen

n8n entfernt den Modus default von N8N_DEFAULT_BINARY_DATA_MODE, bei dem Binärdaten während der Ausführung im Arbeitsspeicher gespeichert werden. Ab v2 sind folgende Optionen verfügbar, um bessere Leistung und Stabilität zu bieten:

• filesystem: Binärdaten werden im Dateisystem gespeichert (Standard im Standardmodus).
• database: Binärdaten werden in der Datenbank gespeichert (Standard im Queue-Modus).
• s3: Binärdaten werden in einem S3-kompatiblen Speicher abgelegt.

Auch die Einstellung N8N_AVAILABLE_BINARY_DATA_MODES wird entfernt, sodass der Modus jetzt ausschließlich durch N8N_DEFAULT_BINARY_DATA_MODE bestimmt wird.

Migrationspfad: Je nach Konfiguration wird automatisch der Dateisystem- oder Datenbankmodus verwendet. Stelle sicher, dass deine n8n-Instanz über ausreichend Speicherplatz verfügt, um Binärdaten zu speichern. Weitere Informationen findest du unter Konfiguration von Binärdaten.

Konfiguration und Umgebung

dotenv aktualisieren

n8n verwendet die Bibliothek dotenv, um Umgebungskonfigurationen aus der Datei .env zu laden. Diese Bibliothek wird von Version 8.6.0 auf die neueste Version aktualisiert, was die Verarbeitung von .env-Dateien verändern kann. Zu den wichtigsten Breaking Changes gehören:

• Unterstützung für Backticks (#615): Wenn deine Werte Backticks enthalten, schließe sie in einfache oder doppelte Anführungszeichen ein.
• Unterstützung für mehrere Zeilen: Mehrzeilige Werte sind jetzt möglich.
• # kennzeichnet den Beginn eines Kommentars: Entsprechender Text wird als Kommentar interpretiert.

Migrationspfad: Lies das dotenv-Changelog und aktualisiere deine .env-Datei, damit sie mit der neuen Version kompatibel ist.

Option n8n --tunnel entfernen

Die Befehlszeilenoption n8n --tunnel wird in v2.0 entfernt.

Migrationspfad: Wenn du die Option --tunnel derzeit für Entwicklung oder Tests verwendest, wechsle zu einer anderen Tunneling-Lösung wie ngrok, localtunnel oder Cloudflare Tunnel. Aktualisiere deine Workflows und Dokumentation entsprechend.

QUEUE_WORKER_MAX_STALLED_COUNT entfernen

Die Umgebungsvariable QUEUE_WORKER_MAX_STALLED_COUNT und der Retry-Mechanismus von Bull für festgefahrene Jobs werden entfernt, da sie häufig für Verwirrung sorgen und unzuverlässig funktionieren.

Migrationspfad: Entferne diese Umgebungsvariable aus deiner Konfiguration. Nach dem Upgrade versucht n8n nicht mehr automatisch, festgefahrene Jobs erneut auszuführen. Wenn du solche Jobs behandeln musst, solltest du eine eigene Retry-Logik oder ein Monitoring implementieren.

N8N_CONFIG_FILES entfernen

Die Umgebungsvariable N8N_CONFIG_FILES wurde entfernt.

Migrationspfad: Entferne diese Umgebungsvariable aus deiner Konfiguration. Migriere die Konfiguration in Umgebungsvariablen, .env-Dateien oder _FILE-basierte Konfigurationen.

CLI und Workflows

CLI-Befehl update:workflow ersetzen

Der CLI-Befehl update:workflow wird als veraltet markiert und durch zwei neue Befehle ersetzt, die ähnliche Funktionen mit klarerer Semantik bereitstellen:

• publish:workflow mit den Parametern id und versionId (optional)
• Der Parameter --all wird entfernt, um ein versehentliches Veröffentlichen von Workflows in Produktionsumgebungen zu verhindern
• unpublish:workflow mit dem Parameter id sowie dem Flag --all

Migrationspfad: Verwende den neuen Befehl publish:workflow, um Workflows anhand ihrer ID einzeln zu veröffentlichen, optional mit einer bestimmten Version. Zum Aufheben der Veröffentlichung verwende den neuen Befehl unpublish:workflow. Das sorgt für mehr Klarheit und bessere Kontrolle über den Veröffentlichungsstatus von Workflows.

Externe Hooks (External Hooks)

Frontend-Workflow-Hooks als veraltet markieren

Die Hook-Funktionen workflow.activeChange und workflow.activeChangeCurrent werden als veraltet markiert und durch den neuen Hook workflow.published ersetzt. Der neue Hook wird ausgelöst, wenn eine beliebige Version eines Workflows veröffentlicht wird.

Migrationspfad: Aktualisiere deinen Code, sodass statt workflow.activeChange und workflow.activeChangeCurrent der neue Hook workflow.published verwendet wird. Dieser Hook bietet ein konsistenteres Verhalten und wird ausgelöst, wenn eine Workflow-Version veröffentlicht wird.

Release-Kanäle

n8n hat die Release-Kanäle von latest und next in stable beziehungsweise beta umbenannt.

Das Tag stable bezeichnet die neueste stabile Version, beta die neueste experimentelle Version. Diese Tags sind sowohl auf npm als auch auf Docker Hub verfügbar. Aktuell versieht n8n Releases weiterhin zusätzlich mit den Tags latest und next. Diese Tags werden in einer zukünftigen Hauptversion entfernt.

Empfehlung: Lege deine n8n-Version auf eine konkrete Versionsnummer fest, zum Beispiel 2.0.0.

Feedback zu Problemen

Wenn bei der Aktualisierung auf n8n 2.0 Probleme auftreten, besuche das Community-Forum für Hilfe und Support.