n8n 2.0: Das Hardening Release, das wir brauchten

n8n 2.0 ist am 8. Dezember 2024 erschienen, und es ist die Art von Release, über die sich zunächst niemand so richtig freut, die aber jeder irgendwann zu schätzen weiß. Keine glänzenden neuen Features, keine schicken UI-Updates. Version 2.0 ist das, was n8n ein "Hardening Release" nennt – ein Release, das sich ausschließlich darauf konzentriert, die Plattform sicherer, stabiler und Enterprise-tauglicher zu machen.

Das große Ganze: Security by Default

Die gesamte Release-Philosophie lässt sich so zusammenfassen: n8n standardmäßig sicher machen, statt Sicherheit über Konfiguration zu erreichen. Das bedeutet: Dinge, die früher offen waren, werden jetzt gesperrt. Prozesse, die früher zusammen liefen, werden jetzt isoliert. Und Features, die Sicherheitsprobleme verursachten, werden entfernt.

Das wird einige Workflows zum Absturz bringen. Und das ist Absicht.

Drei Änderungen, die wirklich wichtig sind

1. Task Runner sind immer aktiviert

Die größte Änderung: Code-Nodes laufen jetzt standardmäßig in isolierten Prozessen, nicht mehr in der Hauptinstanz von n8n. Das ist es, was Task Runner tun – sie schotten deinen JavaScript- und Python-Code in einer Sandbox ab, sodass ein Memory Leak oder eine Endlosschleife in deinem Workflow nicht die gesamte Plattform zum Absturz bringen kann.

Warum das gut ist: Bessere Stabilität, bessere Sicherheit, echte Ressourcenlimits. Deine Automatisierungsplattform sollte nicht abstürzen, nur weil jemand while(true) {} in einer Code-Node geschrieben hat.

Warum dich das nerven könnte: Task Runner benötigen mehr Infrastruktur. Wenn du n8n auf einem winzigen VPS mit 1GB RAM laufen lässt, könntest du es spüren. Und wenn du Docker mit externen Task Runnern verwendest, musst du das separate n8nio/runners Image zu deinem Setup hinzufügen.

2. Umgebungsvariablen sind gesperrt

Code-Nodes können standardmäßig keine Umgebungsvariablen mehr lesen. Wenn du bisher process.env.SECRET_KEY in deinen Workflows verwendet hast, funktioniert das in 2.0 nicht mehr.

Die Begründung: Umgebungsvariablen enthalten oft sensible Daten, und Code-Nodes hatten uneingeschränkten Zugriff darauf. Nicht optimal, wenn du Community-Workflows ausführst oder mehrere Teams dieselbe n8n-Instanz verwenden lässt.

Du kannst N8N_BLOCK_ENV_ACCESS_IN_NODE=false setzen, um das alte Verhalten wiederherzustellen, aber der bessere Weg ist die Nutzung des Credential-Systems von n8n. Dafür ist es da.

3. Gefährliche Nodes sind deaktiviert

Die Nodes ExecuteCommand und LocalFileTrigger sind standardmäßig deaktiviert, weil sie es Workflows ermöglichen, beliebige Shell-Befehle auszuführen und das Dateisystem zu überwachen. Wenn du weißt, warum du sie brauchst, kannst du sie wieder aktivieren. Wenn du nicht weißt, warum du sie brauchst, brauchst du sie wahrscheinlich nicht.

Die gleiche Logik gilt für die Bare-Repository-Unterstützung des Git-Nodes – standardmäßig deaktiviert, aktiviere sie, wenn du sie wirklich benötigst.

Datenbank-Aufräumen: MySQL ist raus

MySQL- und MariaDB-Support ist weg. Sie haben es in v1.0 als deprecated markiert, und jetzt ziehen sie den Stecker. PostgreSQL ist die empfohlene Datenbank, und SQLite funktioniert gut für kleinere Setups.

Die SQLite-Geschichte wird in 2.0 sogar besser – sie entfernen den alten Treiber und machen den Pool-Treiber (der den WAL-Modus verwendet) zur einzigen Option. Benchmarks zeigen, dass er bis zu 10x schneller ist, und ehrlich gesagt war die SQLite-Performance ohnehin nie das Problem.

Auch die Behandlung von Binärdaten ändert sich: Der In-Memory-Modus wird entfernt. Du bekommst Dateisystem-Speicherung, Datenbank-Speicherung oder S3. Such dir eins aus. Wir würden behaupten, dass sowieso niemand den In-Memory-Modus in der Produktion hätte verwenden sollen – das war ein Ressourcen-Management-Albtraum, der nur darauf wartete, zu passieren.

Python bekommt ein Rewrite

Pyodide-basierte Python Code-Nodes sind raus, ersetzt durch native Python-Ausführung über Task Runner. Das ist objektiv besser – natives Python ist schneller und kompatibler – aber es ändert die API.

Die alte Pyodide-Version hatte praktische Variablen wie _input und unterstützte Punkt-Notation für den Datenzugriff. Die neue native Version tut das nicht. Wenn du Python-Workflows hast, musst du sie aktualisieren. Die Dokumentation hat mehr Details.

Wichtig zu wissen: Natives Python funktioniert nur mit Task Runnern im External Mode, was bedeutet, dass du tatsächlich Python in deiner Umgebung installiert haben musst. Für manche Setups ist das trivial. Für andere (wir schauen dich an, stark containerisierte Deployments) ist es eine weitere Sache, die gemanagt werden muss.

Was kaputt geht und was nicht

Das wird definitiv kaputt gehen:

• Code-Nodes, die process.env lesen, ohne Konfigurationsänderungen
• Workflows, die ExecuteCommand- oder LocalFileTrigger-Nodes verwenden (außer du whitelistest sie)
• Python Code-Nodes mit Pyodide-spezifischer Syntax
• Dateioperationen, die versuchen, auf Pfade außerhalb von ~/.n8n-files zuzugreifen
• Alle, die noch auf MySQL oder MariaDB sind

Das wird wahrscheinlich nicht kaputt gehen:

• Reguläre Integrationen und Built-in-Nodes
• HTTP-Requests und Webhooks
• Die meisten JavaScript Code-Nodes (außer sie greifen auf Umgebungsvariablen zu)
• Datenbank-Queries (solange du nicht auf MySQL bist)

Die vier entfernten Nodes – Spontit, crowd.dev, Kitemaker, Automizy – sind nur relevant, wenn du sie tatsächlich verwendest, und da diese Services tot sind, waren deine Workflows wahrscheinlich schon vorher kaputt.

Solltest du upgraden?

Wenn du frisch startest: Auf jeden Fall. Nutze einfach 2.0.

Wenn du 1.x in Produktion laufen hast: Keine Eile. n8n wird 1.x für die nächsten 3 Monate weiterhin für kritische Sicherheitsprobleme patchen, du hast also Zeit, die Migration ordentlich zu planen.

Wenn du in einer regulierten Branche oder im Enterprise-Umfeld bist: Fang jetzt an zu planen. Die Sicherheitsverbesserungen in 2.0 sind genau das, was du für Compliance brauchst, und je länger du wartest, desto schwieriger wird die Migration.

Das v2.0 Migration Tool ist es wert, ausgeführt zu werden – es scannt dein Setup und sagt dir, was kaputt geht.

Die ehrliche Bewertung

n8n 2.0 ist Wartung, keine Innovation. Es ist die Art von Release, die keine Blog-Schlagzeilen generiert, aber die Plattform auf eine Art besser macht, die sich langfristig summiert. Isolierte Ausführung, strengere Defaults, sauberere Datenbank-Unterstützung.

Die Breaking Changes sind real, aber sie sind nicht willkürlich. Alles, was kaputt geht, war entweder ein Sicherheitsrisiko oder ein veraltetes Feature, das ohnehin hätte entfernt werden sollen. Wenn du betroffen bist, wirst du ein paar Stunden damit verbringen, Workflows zu aktualisieren. Das nervt, aber es ist nicht das Ende der Welt.

Wird das n8n enterprise-tauglicher machen? Wahrscheinlich. Wird es einige Power-User frustrieren, die die alten flexiblen-aber-gefährlichen Defaults mochten? Definitiv. Ist es der richtige Schritt? Ja, daran besteht kein Zweifel.

Wenn du gerade Workflow-Automatisierungs-Tools evaluierst und Sicherheit dir wichtig ist, ist n8n 2.0 ein bedeutender Schritt in die richtige Richtung. Wenn du bereits auf n8n bist und dem Upgrade mit Unbehagen entgegensiehst, denk daran: In sechs Monaten wirst du dich fragen, warum irgendjemand gedacht hat, dass es eine gute Idee war, unvertrauenswürdigen Code im Hauptanwendungsprozess laufen zu lassen.