n8n 3.0 ist in der Beta: Was beim Umstieg kaputtgeht und was der Migration Report wirklich prüft

Am 27. Oktober hat n8n die Beta von Version 3.0 veröffentlicht. Die stabile Fassung soll laut Hersteller Anfang Dezember folgen. Für Betriebe, die n8n selbst hosten, ist das kein Update wie jede Woche. n8n schreibt es selbst ohne Umschweife: Von 3.x führt kein Weg zurück auf 2.x, außer über eine Sicherung.

Wir betreiben n8n selbst, mit 29 Workflows in Docker neben einer PostgreSQL-Datenbank. Wir haben heute den eingebauten Migration Report auf einer Kopie dieser Instanz laufen lassen. Dabei haben wir zwei Dinge gelernt, die in der Ankündigung nicht stehen: Ein leerer Bericht heißt nicht viel, wenn man ihn nicht vorher gegen einen kaputten Workflow geprüft hat. Und an einer Stelle fragt der Bericht nur ab, ob eine Einstellung gesetzt ist, nicht ob die eigenen Workflows mit dem neuen Verhalten zurechtkommen.

Was n8n angekündigt hat

Die Ankündigung im n8n-Blog nennt die Eckdaten:

• Beta seit 27. Oktober 2026, stabile Fassung „early December“. Das ist Planung, kein zugesagtes Datum.
• Kein Rückweg: „There’s no going back to 2.x.“ Vor dem Update eine vollständige Sicherung anlegen, zurück geht es nur durch deren Einspielen.
• Unterstützung: 1.x endet am 31. Dezember 2026. 2.x bekommt nach dem stabilen Start von 3.0 noch zwölf Monate Sicherheitskorrekturen und Korrekturen kritischer Fehler. Neue Funktionen gibt es nur noch in 3.x.
• Empfohlene Reihenfolge: erst auf die neueste 2.x, dort den Migration Report öffnen, alles Markierte beheben oder bewusst als „won’t fix“ markieren, dann sichern, zuerst eine Test- oder Staging-Instanz umstellen und erst danach die Produktion.

Zur Lizenz sagt die Ankündigung nichts. Wir gehen deshalb nicht davon aus, dass sich dort etwas ändert, behaupten es aber auch nicht.

Was sich ändert

Die vollständige Liste steht in der Dokumentation zu den Breaking Changes. Für einen typischen selbst gehosteten Betrieb sind das die Punkte, die man vor dem Update kennen sollte:

Bereich	Änderung	Wen es trifft
Installation	Kein npm/npx n8n mehr, selbst gehostet nur noch Docker	Alle, die n8n direkt mit Node.js betreiben
Nodes	Function, Function Item, Item Lists, Cron, Interval, Read/Write Binary File, Read PDF, alter OpenAI-Node, AI Agent v1 und mehr entfernt	Ältere Workflows, die nie umgebaut wurden
Code-Node	Vorgabe für N8N_RUNNERS_TASK_TIMEOUT sinkt von 300 auf 60 Sekunden	Code, der länger als eine Minute rechnet
Compression-Node	Entpackgrenze 2 GiB auf 256 MiB, Einträge je ZIP 5.000 auf 1.000	Große Archive, Datenimporte
Community-Pakete	N8N_UNVERIFIED_PACKAGES_ENABLED wird false, nicht geprüfte Pakete laden nicht mehr	Wer Community-Nodes aus npm installiert hat
Speicher	Ordner binaryData heißt jetzt storage; n8n startet nicht, wenn beide existieren	Instanzen mit Dateispeicher
Slack	Slack-Trigger braucht ein Signing Secret, sonst 401	Alle Slack-Trigger
Gmail	Trigger 1 bis 1.3 laufen als 1.4, Entwürfe werden übersprungen, gesendete Mails lösen nicht mehr aus	Gmail-Trigger auf alten Versionen
Netz	SSRF-Sperrliste wächst, unter anderem um 100.64.0.0/10	Wer die SSRF-Sperre nutzt und Dienste in diesem Bereich anspricht, etwa über Tailscale
Chat-Trigger	Jede WebSocket-Nachricht ist ein JSON-Objekt, @n8n/chat ab 1.31.0	Eigene Chat-Oberflächen
Editor	Import per URL entfernt, Ask-AI-Reiter im Code-Node entfernt	Bedienung, keine laufenden Workflows

Unser Test: der Migration Report auf einer Kopie

Den Bericht kann nur ein Konto sehen, das alle Workflows bearbeiten darf, und beim Erzeugen schreibt n8n in die eigene Datenbank. Wir haben ihn deshalb nicht in der laufenden Instanz geöffnet, sondern so:

1. Die Datenbank mit pg_dump gesichert und in eine Wegwerf-PostgreSQL eingespielt.
2. Eine zweite n8n 2.45.5 mit derselben Konfiguration gestartet, in einem Docker-Netz ohne Weg nach draußen (docker network create --internal).
3. In der Kopie alle 29 Workflows deaktiviert, damit kein Zeitplan auslöst.
4. Den Bericht für Version 3 erzeugt und abgerufen, über dieselbe interne Schnittstelle, die auch die Seite Settings, Migration Report nutzt. Ohne Angabe prüft sie in 2.45.5 noch gegen Version 2. Wer sie selbst abfragt, muss version=v3 mitgeben.

Danach haben wir Kopie, Netz und Dump wieder gelöscht. Die laufende Instanz hat davon nichts mitbekommen.

Das Ergebnis für unsere Instanz: ein einziger Hinweis auf Ebene der Instanz, nämlich dass der Import per URL entfällt. Kein einziger Workflow markiert.

Ein leerer Bericht muss sich erst beweisen

Null Treffer kann heißen, dass alles in Ordnung ist. Es kann auch heißen, dass die Prüfung gar nicht hinsieht. Wir haben deshalb in die Kopie einen Workflow geschrieben, der genau die Nodes enthält, die 3.0 entfernt: Cron, Function und Item Lists.

Dabei die erste Überraschung. Über die Oberfläche oder die Schnittstelle lässt sich ein solcher Workflow in 2.45.5 gar nicht mehr anlegen. n8n antwortet mit „this node type is deprecated“ und speichert nichts. Alte Workflows, die diese Nodes schon enthalten, laufen aber weiter. Wir haben den Workflow deshalb direkt in die Datenbank der Kopie geschrieben, so wie er in einer älteren Instanz liegen würde.

Danach meldet der Bericht drei Regeln mit je einem betroffenen Workflow: cron-removed, function-removed und item-lists-removed. Die Prüfung auf entfernte Nodes funktioniert also. Unsere Null ist echt: Eine Abfrage über alle Knoten unserer Workflows zeigt ebenfalls keinen einzigen der entfernten Typen. Der AI Agent läuft bei uns in Version 2, betroffen ist nur Version 1.

Warum unser Bericht so kurz ist

Mitte September hat n8n angekündigt, vier Vorgaben in einer künftigen Version zu ändern. Wir haben sie damals in unserer Docker-Konfiguration fest eingetragen, damit ein Update das Verhalten nicht still verschiebt:

N8N_UNVERIFIED_PACKAGES_ENABLED: "false"   # künftige Vorgabe schon jetzt
N8N_RUNNERS_TASK_TIMEOUT: "300"            # Sekunden, alter Wert
N8N_COMPRESSION_NODE_MAX_DECOMPRESSED_SIZE_BYTES: "2147483648"
N8N_COMPRESSION_NODE_MAX_ZIP_ENTRIES: "5000"

Zum Vergleich haben wir die Kopie ohne diese vier Zeilen neu gestartet und den Bericht noch einmal erzeugt. Jetzt meldet er vier Regeln auf Ebene der Instanz statt einer: die gesenkten Grenzen im Compression-Node, die kürzere Laufzeit im Code-Node, eine Warnung zu nicht geprüften Community-Paketen und den Import per URL.

Wo der Bericht nur die Einstellung prüft

Hier liegt der eigentliche Fund. Die Regel zur Laufzeit im Code-Node prüft im Quelltext von n8n genau eine Sache: ob N8N_RUNNERS_TASK_TIMEOUT gesetzt ist. Ist die Variable gesetzt, gilt die Instanz als nicht betroffen, egal mit welchem Wert. Ist sie nicht gesetzt, kommt ein Hinweis der Stufe „info“. Ob irgendein Code-Node tatsächlich länger als eine Minute läuft, schaut sie sich nicht an.

Das muss man selbst nachsehen. Wir haben dafür die Ausführungen genommen, die unsere Instanz noch aufbewahrt hatte, vom 15. bis 29. Oktober. 22 unserer Workflows enthalten einen Code-Node, 16 davon sind in dieser Zeit gelaufen, zusammen 678 Mal. Eine einzige Ausführung dauerte länger als 60 Sekunden, 1 Minute 32. Das war ein Agenten-Workflow, der ein Sprachmodell aufruft. Die Zahl ist die Gesamtdauer der Ausführung, nicht die Zeit im Code-Node. Vermutlich steckt der größte Teil im Modellaufruf, sicher wissen wir es daraus nicht. Wer seine eigene Instanz so prüfen will, kommt mit einer Abfrage auf die Tabelle execution_entity aus (Spalten startedAt und stoppedAt).

Wer die Variable nicht gesetzt hat und Code-Nodes mit langen Schleifen, großen Dateien oder Abrufen in Schleifen betreibt, sollte das vor dem Update klären. Sonst bricht n8n diese Aufgaben ab der stabilen 3.0 nach 60 Sekunden ab.

Was der Bericht nicht kennt

Einen Punkt fanden wir weder im Bericht noch in der Liste der Breaking Changes. Wir laden einen eigenen Node, keinen aus npm, sondern über N8N_CUSTOM_EXTENSIONS aus einem Verzeichnis. Die Regel zu Community-Paketen betrifft ihn nach unserem Verständnis nicht, weil der Lader dieses Verzeichnis ohne den Paket-Installer liest. Ob das in 3.0 so bleibt, sagt die Dokumentation nicht. Wir prüfen das auf der Beta in einer Testinstanz, bevor wir unsere Produktion umstellen, und tragen das Ergebnis hier nach.

Ebenso wenig sieht der Bericht in Skripte außerhalb von n8n. Wer Workflows über die Kommandozeile oder die Schnittstelle von außen steuert, muss diese Aufrufe selbst durchgehen.

Checkliste vor dem Update

• Erst auf die neueste 2.x. Dort steckt die aktuellste Fassung des Berichts.
• Bericht auf einer Kopie erzeugen, nicht in der Produktion. Und einmal mit einem absichtlich veralteten Workflow prüfen, ob er anschlägt.
• Laufzeiten selbst messen. Längste Ausführung von Workflows mit Code-Node ansehen, nicht nur den Bericht lesen.
• Grenzen bewusst festlegen. Wer das alte Verhalten braucht, trägt N8N_RUNNERS_TASK_TIMEOUT und die Compression-Grenzen ausdrücklich ein und schreibt dazu, warum.
• Installation prüfen. Läuft n8n per npm, ist vor 3.0 der Umzug nach Docker fällig.
• Slack-, Gmail- und Chat-Trigger einzeln ansehen. Sie ändern ihr Verhalten, ohne dass ein Workflow als defekt markiert wird.
• Sicherung von Datenbank und Datenordner, und zwar so, dass man das Einspielen schon einmal ausprobiert hat.
• Nicht am ersten Tag. Wir bleiben auf 2.x, bis die stabile 3.0 da ist und die ersten Korrekturen erschienen sind. Die Beta testen wir parallel.

Wie wir n8n grundsätzlich betreiben, mit Preisen, Lizenz und Datenschutz, steht in unserem Beitrag n8n im Unternehmen: Cloud oder selbst hosten?. Wann ein fester Ablauf reicht und wann ein KI-Agent sinnvoll ist, erklären wir unter KI-Agent oder Automatisierung.

Wer neu aufsetzt, bekommt mit unserem n8n-Baukasten eine passende docker-compose.yml mit fest eingetragener Version.

Quellen

Alle abgerufen am 29.10.2026.

• n8n: Introducing n8n v3, 27.10.2026 (Beta, Zeitplan, kein Rückweg zu 2.x, Unterstützung 1.x und 2.x, Migration Report ab 2.39, empfohlene Reihenfolge)
• n8n-Dokumentation: n8n 3.0 breaking changes (vollständige Liste mit Variablen und alten und neuen Werten)
• Eigene Messung vom 29.10.2026: Migration Report (Ziel v3) auf einer Kopie unserer Instanz n8n 2.45.5 mit 29 Workflows, Gegenprobe mit einem Workflow aus Cron, Function und Item Lists, Wiederholung ohne festgeschriebene Variablen, Ausführungsdauern aus execution_entity vom 15. bis 29.10.2026
• Quelltext n8n 2.45.5: Regel task-runner-task-timeout im Modul breaking-changes (prüft nur, ob die Variable gesetzt ist)

Stand: 29. Oktober 2026, Beta 3.0.0. Ändert n8n bis zur stabilen Fassung die Liste oder den Zeitplan, ergänzen wir den Beitrag.