n8n 3.0 entfernt npm-Installationen und bricht Legacy-Workflow-Knoten

Die Automatisierungsplattform n8n bereitet sich auf ein großes Version-3.0-Release vor, das erhebliche Breaking Changes für selbst gehostete Instanzen mit sich bringt. Als Beta am 27. Oktober 2026 veröffentlicht, mit einem geplanten stabilen Launch Anfang Dezember, verändert dieses Update grundlegend, wie die Software bereitgestellt wird und wie bestehende Workflows funktionieren. Teams, die ihre eigenen n8n-Server betreiben, müssen sich auf verpflichtende Infrastrukturänderungen und Code-Refactoring vorbereiten, bevor das Upgrade-Fenster schließt.

Was passiert ist

Die unmittelbarste operative Änderung ist die Entfernung der npm-basierten Installationsmethoden. Version 3.0 wird kein lauffähiges n8n-Paket mehr auf npm veröffentlichen, was bedeutet, dass Befehle wie npm install n8n oder npx n8n nicht mehr unterstützt werden. Self-Hosted-Nutzer müssen zu Docker-Containern migrieren, um die Software auszuführen. Diese Umstellung umfasst auch Änderungen an den Dateispeicherpfaden; das Legacy-Verzeichnis ~/.n8n/binaryData wird durch ~/.n8n/storage ersetzt. Die Anwendung startet nicht, wenn beide Verzeichnisse vorhanden sind, was eine manuelle Bereinigung während des Übergangs erfordert. Darüber hinaus ist die Rotation von Verschlüsselungsschlüsseln jetzt standardmäßig aktiviert, und der Compression-Knoten hat strengere Limits, die Operationen auf 256 MiB oder 1.000 Einträge begrenzen.

Neben der Infrastruktur entfernt das Update mehrere Kernknoten und Funktionen, die in früheren Versionen als veraltet (deprecated) markiert wurden. Die Cron- und Interval-Trigger sind weggefallen und werden vollständig durch den Schedule Trigger ersetzt. Legacy-Knoten wie Function, Function Item und Item Lists wurden entfernt, was dazu führt, dass Ausführungen fehlschlagen, wenn sie noch in älteren Workflows vorhanden sind. Das Migrationstool kann einige davon in Code-Knoten konvertieren, aber eine manuelle Überprüfung ist notwendig. Außerdem wurde die $getPairedItem-Ausdrucksmethode aus Code-Knoten entfernt, sodass Entwickler ihre Skripte aktualisieren müssen, um Alternativen wie .itemMatching() oder .pairedItem() zu nutzen.

Auch die Sicherheits- und Integrationseinstellungen wurden verschärft. Slack-Trigger erfordern jetzt ein Signature Secret in den Credentials, was bestehende Approval- und Alert-Flows stoppt, wenn sie nicht aktualisiert werden. Die Plattform hat ihre Blockliste für Server-Side Request Forgery (SSRF) erweitert, um standardmäßig den Bereich 100.64.0.0/10 einzuschließen, was potenziell Verbindungen zu bestimmten privaten internen Diensten blockiert, es sei denn, sie werden explizit über Umgebungsvariablen auf die Allowlist gesetzt. Unverifizierte Community-Pakete sind standardmäßig deaktiviert, was bedeutet, dass benutzerdefinierte Knoten von Drittanbietern nicht geladen werden, es sei denn, der Nutzer akzeptiert das Risiko ausdrücklich durch das Setzen einer Umgebungsflag.

Wichtige Details

• Änderung der Bereitstellung: npm- und npx-Installationen werden nicht mehr unterstützt; Nutzer müssen zu Docker wechseln.
• Entfernung von Knoten: Die Knoten Cron, Interval, Function, Function Item und Item Lists wurden gelöscht.
• Code-Änderungen: $getPairedItem wurde entfernt; die Standard-Timeouts für Code-Aufgaben sinken von 300 s auf 60 s.
• Slack-Integration: Trigger verlangen nun zwingend ein Signature Secret in der Credential-Konfiguration.
• Speicherpfad: ~/.n8n/binaryData wurde in ~/.n8n/storage umbenannt; der alte Pfad muss entfernt werden.
• Support-Zeitplan: Der Support für Version 1.x endet am 31. Dezember 2026; Sicherheitsupdates für 2.x enden 12 Monate nach dem stabilen Release von 3.x.

Hintergrund

n8n ist ein Workflow-Automatisierungstool, das es Nutzern ermöglicht, verschiedene Apps und Dienste über eine visuelle Oberfläche zu verbinden. Für viele Unternehmen, insbesondere solche, die sensible Daten verarbeiten, bietet das Self-Hosting von n8n Kontrolle darüber, wo Daten gespeichert werden und wie sie verarbeitet werden. Die Wartung selbst gehosteter Software erfordert jedoch, dass man mit den Upstream-Änderungen Schritt hält. Breaking Changes in Major-Versionen beinhalten oft die Entfernung veralteter Funktionen, um technische Schulden zu reduzieren und die Sicherheit zu verbessern. In diesem Kontext vereinfacht die Entfernung der npm-Unterstützung die Wartungslast für die Entwickler, indem sie sich auf ein einzelnes, containerisiertes Bereitstellungsmodell konzentrieren. Ebenso zwingt die Entfernung von Legacy-Knoten Nutzer dazu, modernere, effizientere und sicherere Coding-Praktiken innerhalb ihrer Workflows anzunehmen.

Warum es wichtig ist

Für Teams, die ihre eigene Automatisierungsinfrastruktur verwalten, ist dieses Upgrade nicht optional, wenn sie weiterhin Support erhalten möchten. Die Entfernung der npm-Unterstützung bedeutet, dass alle bestehenden CI/CD-Pipelines oder Server-Setups, die auf direkter Node-Installation beruhen, beim Upgrade brechen. Dies erfordert eine grundlegende Re-Architektur der Deployment-Skripte. Darüber hinaus kann die harte Reduzierung des Timeouts für Code-Knoten von 300 Sekunden auf 60 Sekunden dazu führen, dass langlaufende Datentransformationen unerwartet fehlschlagen. Teams, die große Datensätze verarbeiten oder komplexe Berechnungen in JavaScript-Code-Knoten durchführen, müssen entweder ihre Skripte optimieren oder die Umgebungsvariable N8N_RUNNERS_TASK_TIMEOUT konfigurieren, um Produktionsausfälle zu verhindern.

Die Auswirkungen auf geschäftskritische Workflows sind erheblich. Flows, die Bestellungen, Rechnungen oder Lagerbewegungen bearbeiten, verlassen sich oft auf Legacy-Knoten oder spezifische Timing-Trigger. Wenn diese nicht identifiziert und vor dem Upgrade migriert werden, könnten Geschäftsprozesse zum Stillstand kommen. Die Anforderung, automatisch migrierte Workflows manuell zu überprüfen, fügt eine Schicht an Quality-Assurance-Arbeit hinzu, die nicht übersprungen werden kann. Zusätzlich können die strengeren SSRF-Schutzmaßnahmen stillschweigend interne API-Aufrufe blockieren, die zuvor erlaubt waren, was Netzwerkteams dazu zwingt, Allowlists für private IP-Bereiche zu überprüfen und zu aktualisieren.

Was Sie tun können

• Überprüfen Sie Ihre aktuelle Version: Wenn Sie Version 1.x verwenden, upgraden Sie zuerst auf 2.x, da es keinen direkten Pfad zu 3.x gibt.
• Führen Sie den Migrationsbericht aus: Nutzen Sie das integrierte Tool in den Einstellungen (verfügbar in n8n 2.39+), um Workflow- und Instanzprobleme zu identifizieren.
• Priorisieren Sie kritische Flows: Beheben Sie Workflows, die an finanziellen oder Inventartransaktionen beteiligt sind, zuerst und überprüfen Sie automatisch migrierten Code sorgfältig.
• Auditieren Sie Code-Knoten: Suchen Sie nach veralteten Methoden wie $getPairedItem und identifizieren Sie Aufgaben, die länger als 60 Sekunden laufen.
• Testen Sie in Staging: Sichern Sie Ihre Produktionsinstanz, stellen Sie sie in einer Staging-Umgebung wieder her, führen Sie das Upgrade durch und spielen Sie reale Eingaben ab, um die Datensatzanzahlen zu überprüfen.
• Planen Sie Downtime: Führen Sie das finale Upgrade in einer ruhigen Phase durch und bestätigen Sie danach, dass alle geplanten Workflows korrekt aktivieren.