n8n 3.0: Was bricht, wen es trifft und wie du mit dem Migration Report umsteigst

Ist n8n 3.0 schon da?

Noch nicht final. Auf Docker Hub liegt seit dem 12. Oktober 2026 ein Image mit dem Tag v3-rc, also ein Release Candidate zum Testen. Auf GitHub ist am 13. Oktober die neueste Version 2.44.0, ein Release mit 3er-Nummer gibt es dort nicht. Die Doku-Seite zu den Breaking Changes von n8n 3.0 spricht trotzdem schon von einer Veröffentlichung. Verlass dich darauf nicht, sondern auf die Versionsnummer in deiner Instanz.

Wichtig für den Zeitplan: n8n bringt laut Release Notes fast jede Woche eine neue Minor-Version. Der Abstand zwischen Release Candidate und finaler Version kann also kurz sein. Wer jetzt vorbereitet, hat beim Update keinen Stress.

Was ist der Migration Report und wo finde ich ihn?

Der Migration Report prüft deine eigene Instanz gegen die Änderungen von 3.0. Du findest ihn unter Settings > Migration Report. Er zeigt, welche Workflows betroffen sind und welche Instanz-Einstellungen du anpassen musst. Sehen können ihn laut Doku zum Vorgänger-Werkzeug nur globale Admins.

Mit Version 2.43 vom 6. Oktober hat n8n den Report umgebaut (Release Notes): Statt Schweregraden gibt es jetzt vier Wirkungskategorien, Blocker stehen oben, dazu ein Fortschrittsbalken der kompatiblen Workflows.

Unsere Einschätzung: Die dritte Zeile ist die gefährlichste. Ein abgebrochener Workflow fällt auf, ein Workflow, der still etwas anderes tut, oft erst nach Wochen.

Welche Änderungen brechen Workflows sofort?

Alles, was entfernt wird, führt zu Fehlern: „Workflows that use a removed node fail“, schreibt n8n. Die häufigsten Fälle in gewachsenen Instanzen:

• Function und Function Item: ersetzen durch den Code-Node, Modus „Run Once for All Items“ bzw. „Run Once for Each Item“
• Item Lists: ersetzen durch den passenden Einzel-Node (Split Out, Aggregate, Sort, Limit, Remove Duplicates oder Summarize)
• Cron und Interval: ersetzen durch den Schedule Trigger
• Read PDF, Read/Write Binary File, Convert to/from binary data: ersetzen durch Extract from File, Convert to File oder Read/Write Files from Disk
• AI Agent Version 1 mit den Modi SQL Agent, ReAct, Conversational und Co.: auf die aktuelle Version mit Tools Agent heben
• Legacy-OpenAI-Nodes, SerpApi, Zep, Motorhead, LangChain Code: teils mit Ersatz, teils ohne; die Liste steht in der Doku
• Ausdruck $getPairedItem: schlägt beim Ausführen fehl, Ersatz ist $('Node-Name').item
• Execute Sub-workflow mit Quelle „Local File“ oder „URL“: Unter-Workflow importieren und über „Database“ auswählen

Eine gute Nachricht: Den AI Transform-Node baut n8n beim Update selbst in einen Code-Node mit demselben JavaScript um.

Welche Änderungen fallen erst später auf?

Diese Punkte erzeugen keinen roten Fehler, sondern andere Ergebnisse oder Ausfälle, die erst bei einem bestimmten Ereignis auftreten:

1. Gmail Trigger in Version 1 bis 1.3 läuft künftig wie Version 1.4. Pro Abruf holt er standardmäßig 10 Mails (einstellbar bis 50), Entwürfe nur noch mit dem Filter „Include Drafts“, und gesendete oder geplante Mails lösen nichts mehr aus. Wer etwa ausgehende Angebote per Gmail Trigger protokolliert, verliert diese Läufe ohne Fehlermeldung.
2. Always Output Data bei If und Switch: Ein leeres Item entsteht nur noch, wenn alle Ausgänge leer sind. Bisher bekam jeder leere Ausgang eines, laut n8n liefen dadurch Zweige, die nicht laufen sollten. Prüfe Workflows, die sich genau darauf verlassen haben.
3. Slack Trigger: Die Slack-Zugangsdaten brauchen ein Signing Secret. Fehlt es, lässt sich der Workflow nicht veröffentlichen und der Trigger antwortet mit Fehler 401, Slack-Ereignisse kommen also nicht mehr an. Das Secret steht in der Slack-App unter Basic Information.
4. Webflow-Zugang (OAuth2): Der Schalter „Legacy“ ist standardmäßig aus. Bestehende Verbindungen laufen weiter, aber beim nächsten Neuverbinden fragt n8n die Berechtigungen der Webflow-API v2 an. Wer noch die alte API v1 nutzt, muss „Legacy“ vorher einschalten, sonst lehnt Webflow die Verbindung ab.
5. Code-Node mit langer Laufzeit: Die Zeitgrenze für Code-Aufgaben (N8N_RUNNERS_TASK_TIMEOUT) sinkt von 300 auf 60 Sekunden. Längere Aufgaben brechen ab. Typischer Kandidat: Code, der große Dateien oder viele Datensätze in einer Schleife verarbeitet.

Was ändert sich für Self-Hosting?

Für selbst betriebene Instanzen ist 3.0 auch ein Infrastruktur-Update. Die vier Punkte mit der größten Wirkung:

• Nur noch Docker: Installationen über npm oder npx n8n werden nicht mehr unterstützt, n8n veröffentlicht kein lauffähiges npm-Paket mehr. Für Teams und Produktion empfiehlt n8n Docker Compose mit Postgres statt der mitgelieferten SQLite-Datenbank.
• Community Nodes: N8N_UNVERIFIED_PACKAGES_ENABLED steht künftig auf false. Nicht verifizierte Community Nodes (Erweiterungen von Dritten) laden danach nicht mehr. Entweder die Variable bewusst auf true setzen oder auf verifizierte Nodes wechseln.
• Speicherordner: ~/.n8n/binaryData heißt jetzt ~/.n8n/storage. Wer ein Volume auf den alten Pfad gemountet hat, muss das anpassen. Existieren beide Ordner, startet n8n nicht.
• SSRF-Schutz (Sperre gegen Anfragen ins eigene Netz): Ist er aktiv, blockt n8n zusätzlich vier Adressbereiche, darunter 100.64.0.0/10. Rufen deine Workflows interne Dienste in diesen Bereichen auf, musst du sie freigeben.

Dazu kommen kleinere Punkte: Der Compression-Node entpackt standardmäßig nur noch bis 256 MiB statt 2 GiB, und Chat Hub ist ab 3.0 standardmäßig aus und fällt mit n8n 4.0 ganz weg.

Und auf n8n Cloud?

Auf n8n Cloud entfallen Docker, Speicherpfade und Umgebungsvariablen, die Workflow-Punkte gelten aber genauso. Unter Updates & maintenance wählt der Instance Owner Version, Release Track (Beta oder Stable) und Update-Rhythmus. n8n empfiehlt Stable für geschäftskritische Workflows, ein Versionswechsel startet die Instanz für ein bis zwei Minuten neu. Wie und wann Cloud-Workspaces auf 3.0 gehoben werden, beschreibt diese Seite am 13. Oktober nicht. Den Migration Report also auch in der Cloud jetzt öffnen.

In welcher Reihenfolge stellst du um?

Unsere empfohlene Reihenfolge:

1. Backup: Datenbank sichern und Workflows exportieren. n8n schaltet mit 3.0 die Rotation der Verschlüsselungsschlüssel standardmäßig ein und rät ausdrücklich zur Sicherung.
2. Migration Report öffnen und die Funde nach Kategorie sortiert abarbeiten: erst „Upgrade blocked“ und „Executions fail“, dann „Behavior changes“.
3. Nodes tauschen, solange du noch auf 2.x bist. Die Ersatz-Nodes gibt es dort schon, du kannst jeden Workflow einzeln testen.
4. Zugänge nachziehen: Slack Signing Secret eintragen, bei Webflow den Legacy-Schalter prüfen.
5. Testlauf auf einer Kopie: Self-Hosted mit dem Image v3-rc auf einer Kopie der Instanz, nie auf der Produktivinstanz. Die wichtigsten Workflows einmal mit echten Daten durchlaufen lassen.
6. Update auf die finale Version, nicht auf den Release Candidate, und in den ersten Tagen die fehlgeschlagenen Ausführungen beobachten.

Was heißt das für dich?

Unsere Einschätzung: Wenn deine Workflows in den letzten zwei Jahren entstanden sind und du regelmäßig aktualisierst, ist der Umstieg meist überschaubar. Aufwendig wird es bei Instanzen, die seit n8n 0.x oder 1.x mitwachsen: Dort stecken Function-Nodes, Cron-Trigger und alte Gmail-Trigger oft in Dutzenden Workflows. Auch die 1.x-Reihe bekommt übrigens noch Patches, zuletzt 1.123.84 am 8. Oktober. Wer dort steht, überspringt mit 3.0 zwei Hauptversionen und sollte mehr Zeit einplanen.

Unser Rat: Nicht am Tag der Veröffentlichung updaten, aber auch nicht monatelang warten. Die Vorbereitung auf 2.x kostet nichts und macht jeden Workflow sauberer, das eigentliche Update ist dann ein kurzer Schritt. Wer noch überlegt, ob n8n überhaupt das richtige Werkzeug ist, findet die Kostenrechnung in unserem Vergleich Make oder n8n. Und wer HubSpot über n8n anbindet, sollte parallel die Umstellung auf Service Keys im Blick behalten.

Wir übernehmen solche Umstiege als Teil unserer KI-Prozessautomatisierung: Report auswerten, Workflows umbauen, auf einer Kopie testen. Wenn du dir den Aufwand für deine Instanz einschätzen lassen willst, schreib uns.