27 veraltete n8n-Nodes zu aktualisieren war so schmerzhaft, dass ich aufgab. Dann schaffte Claude Code es in einem Durchgang.

Letzte Woche mache ich einen Routine-Audit bei einem Client-Workflow. 80 Nodes, ziemlich fett. Ich lasse Claude Code alle Node-Versionen scannen, nur um zu sehen, wo wir stehen. 27 veraltete Nodes. Ok klar, läuft trotzdem, ist nicht das Ende der Welt.

Nur dass Claude etwas flaggt, was mir komplett entgangen war: die emailSend node läuft auf v1. Aktuell ist v2.1. Und zwischen diesen beiden Versionen ist das ccEmail-Feld nach options gewandert, der Body hat von text auf html gewechselt. In der Praxis: Carbon Copies gingen nicht mehr raus. Der E-Mail-Body wurde stillschweigend ignoriert. Null Fehler in den Logs. Lief monatelang so.

Das eigentliche Problem sind nicht die 27 Nodes. Es ist, dass n8n dir nie sagt, wenn eine Node veraltet ist. Es läuft einfach weiter mit der alten Version, und wenn sich Parameterstrukturen zwischen Versionen ändern, schluckt es sie einfach. Keine Warnung, kein Banner, kein "hey, deine E-Mails gehen ins Leere."

Und obendrauf ist das Updaten so mühsam, dass man es immer aufschiebt (gib's zu, machst du genauso). Diff checken, Node neu erstellen, Parameter kopieren, neu verbinden, testen. Mal 27. Mal 50 bis 80 Nodes pro Workflow. Die Art von Arbeit, die man ewig auf nächsten Monat schiebt. Hier ist, wie ich ein dreischichtiges Wartungssystem mit Claude Code gebaut habe, das macht, was n8n self-hosted von sich aus nicht hinkriegt.

Der Audit, der fand, wonach ich nicht gesucht hatte

Der ursprüngliche Plan war nur ein Optimierungspass. Ein Client will, dass ich einen WooCommerce-Workflow tune, der Produktdaten zieht, sie durch ein paar LLM-Ketten anreichert und Updates per API zurückschiebt. Standard-Ecommerce-Pipeline. Ich sollte die Logik anschauen, nicht die Rohrleitungen.

Aber ich habe jetzt diese Angewohnheit. Bevor ich irgendetwas anfasse, lasse ich Claude Code das Workflow-JSON exportieren und einen Versions-Scan laufen. Dauert vielleicht zehn Sekunden. Claude zieht das JSON über n8n-mcp, schickt die Nodes durch jq und spuckt jede Node mit ihrer aktuellen typeVersion versus der neuesten verfügbaren aus.

27 von 80 waren hinten dran. Meist kleinere Bumps (httpRequest, If, Switch, Merge). Ich hätte fast den Tab geschlossen. Dann fing Claude an, Parameterstrukturen zwischen Versionen zu vergleichen. Nicht die Versionsnummern. Die tatsächlichen Schemas.

Da wurde es interessant. Neben dem emailSend-Problem, das ich schon in der Einleitung beschrieben habe, fand Claude tote Äste in bedingten Pfaden (Nodes, die mit Outputs verbunden waren, die neuere Upstream-Versionen nicht mehr triggerten) und Parameter, die im JSON existierten, aber zu nichts in der aktuellen Node-Spec passten. Es liest das Changelog für jede Node-Version und gleicht ab mit dem, was tatsächlich in deinem Workflow ist. Ein Mensch würde das nie manuell bei 80 Nodes machen. Ich sicher nicht.

Claude fand einen stillen Bug, den sechs Monate täglicher Läufe nie an die Oberfläche gebracht hatten.

Aber warum waren diese Nodes überhaupt veraltet? Das ist tatsächlich eine Design-Entscheidung.

n8n friert Node-Versionen by Design ein. Das Problem ist alles danach.

Wenn du eine Node zu einem Workflow hinzufügst, sperrt n8n ihre typeVersion für immer. Den Workflow erstellt, als emailSend bei v1 war? Bleibt v1, bis jemand manuell eingreift. Das ist dokumentiert, beabsichtigt und ehrlich gesagt eine solide Engineering-Entscheidung. Es verhindert, dass Upgrades bestehende Workflows über Nacht kaputtmachen.

Das Problem ist, was danach kommt. In der self-hosted Community Edition gibt es null Tooling, um die Schulden zu verwalten, die das schafft. Keinen "Node updaten"-Button (jemand hat buchstäblich nach einem im n8n Community Forum Anfang 2025 gefragt, und die Antwort war "das gibt es nicht"). Kein Dashboard, das zeigt, welche Nodes hinten dran sind. Keinen Migrations-Wizard. Das Workflow-Versioning, das dir erlauben würde, Änderungen zu verfolgen und rückgängig zu machen? Hinter der Enterprise-Paywall.

Deine einzige offizielle Option: Node löschen, eine frische hinzufügen, jeden Parameter manuell kopieren, jeden Draht neu verbinden. Pro Node. Pro Workflow. Die ganze Mise en Place, etwas zu rebuilden, was schon funktioniert hat.

n8n hat Stabilität gewählt. Der Preis sind unsichtbare Schulden, die niemand verwaltet.

Also habe ich gebaut, was n8n nicht mitliefert. Erste Schicht: ein Sicherheitsnetz.

Schicht 1: Git-Versioning, das n8n für Enterprise reserviert

Ergebnis zuerst: jeder Client hat jetzt ein eigenes GitHub-Repo. Jeder Workflow lebt dort als JSON-Datei. Bevor Claude Code irgendetwas anfasst, committet es den aktuellen Zustand. Nach der Modifikation committet es den neuen Zustand mit einer beschreibenden Nachricht. Vollständiger Diff verfügbar, vollständiger Rollback möglich.

Das ist kein Git-Tutorial (du weißt, wie Git funktioniert). Der Punkt ist, was das ersetzt. n8ns natives Workflow-Versioning (History, Rollback, Diff-View) ist ein Enterprise-Feature. Bei Community Edition self-hosted stellst du aus einem Backup wieder her, wenn du einen Workflow kaputtmachst. Falls du ein Backup hast. Falls es aktuell genug ist.

Claude Code exportiert den Workflow über das n8n-mcp Setup, das ich vorher detailliert beschrieben habe, speichert es ins Repo und committet. Zehn Minuten initiales Setup pro Client. Danach startet jede Wartungsoperation mit git commit und endet mit git commit. Das Sicherheitsnetz existiert, bevor du anfängst zu operieren.

Enterprise-grade Versioning, rebuilt mit Git und Claude Code in zehn Minuten.

Das Netz ist an Ort und Stelle. Jetzt können wir operieren.

Schicht 2: Chirurgische Node-Upgrades via JSON

Der Audit-Befehl. Das ist, was Claude Code laufen lässt, um jede veraltete Node zu inventarisieren:

cat workflow.json | jq '[.nodes[] | {name, type, typeVersion}]'

Claude gleicht jede typeVersion gegen die neueste verfügbare ab und flaggt die Lücken. Bei diesem Workflow kamen 27 Nodes als veraltet zurück. Aber nicht alle veralteten Nodes sind gleich.

Fall 1: Einfache Versions-Bumps. Die httpRequest-Nodes (v4.2 zu v4.4), die If-Nodes (v2.2 zu v2.3), Switch (v3.2 zu v3.4), Merge (v3 zu v3.2). Nichts umbenannt, nichts verschoben. Du änderst buchstäblich nur die typeVersion-Nummer im JSON. Geschenkt.

Fall 2: Parameter-Remapping. Die emailSend (v1 zu v2.1) ist das Paradebeispiel. Das text-Feld wird zu html. Die ccEmail wandert von Top-Level in options. Die allowUnauthorizedCerts-Option verschwindet. Ein neues appendAttribution-Flag taucht auf. Du kannst nicht einfach die Nummer bumpen; du musst die Parameter umstrukturieren.

Das Ganze läuft in einem einzigen jq-Durchgang. Wenn die Aufgabe so chirurgisch ist (präziser Input, präzise Transformation, null Mehrdeutigkeit beim erwarteten Output), ist genau zu strukturieren, was du Claude Code zu tun bittest, was es zuverlässig macht. Hier ist die emailSend-Transformation als Beispiel:

cat workflow.json | jq '
.nodes = [.nodes[] |
  if .type == "n8n-nodes-base.emailSend" and .typeVersion == 1 then
    .typeVersion = 2.1 |
    (if .parameters.text then
      .parameters.html = .parameters.text | del(.parameters.text)
    else . end) |
    (.parameters.ccEmail // null) as $cc |
    .parameters.options = ((.parameters.options // {}) |
      del(.allowUnauthorizedCerts) |
      . + {"appendAttribution": false} +
      (if $cc and $cc != "" then {"ccEmail": $cc} else {} end)) |
    del(.parameters.ccEmail)
  else . end
]'

Der vollständige jq-Befehl deckt alle sieben Node-Typen in einem Durchgang ab (httpRequest, If, Switch, Merge, chainLlm, lmChatOpenAi, emailSend). Gleiches Muster, verschiedene Versionsnummern. Ich habe die komplette Version in einem GitHub Gist, falls du es anpassen willst.

Das transformierte JSON wird auf eine Kopie des Workflows deployed (niemals direkt Production anfassen) über die n8n REST API. Ein PUT-Request, fertig.

Validierung auf der upgegradeten Kopie versus dem Original:

• Errors: 9 bei beiden (alle bereits vorhanden, nichts eingeführt)
• Warnings: 80 vs 109. Die 29 "outdated typeVersion"-Warnungen sind weg.
• Valid connections: 87 bei beiden. Null kaputt.

Verbindungen brechen nie, weil sie Node-Namen referenzieren, nicht Versionen.

80 Nodes gescannt, 27 upgegradet, null Regressionen. Ein jq-Durchgang.

Aber in drei Monaten, wer erinnert sich, was dieser Workflow eigentlich macht?

Schicht 3: Auto-Dokumentation (für Menschen und für Claude)

Für jeden Workflow analysiert Claude Code die vollständige Struktur und schreibt eine interne Notiz direkt in n8n (als Sticky Note auf der Canvas). Die Notiz erklärt, was der Workflow macht: Hauptfluss, bedingte Äste, externe Integrationen, Fehlermodi, Dinge, die komisch aussehen, aber beabsichtigt sind.

Zwei Zielgruppen für dasselbe Dokument. Ein Mensch (oder ein Client) kann den Workflow verstehen, ohne durch 80 Nodes zu lesen. Und wenn Claude Code Wochen später zu diesem Workflow zurückkommt, liest es die Notiz, anstatt das gesamte JSON neu zu parsen. Es ist ein menschenlesbarer Context-Cache.

Bei diesem speziellen Workflow brachte der Dokumentationspass etwas Lustiges zutage: einen bedingten Ast, der zu Nodes führte, die verbunden, aber unerreichbar waren. Die Upstream-If-Node war irgendwann modifiziert worden und der "false"-Output war nicht mehr mit etwas Aktivem verdrahtet. Niemand hatte es bemerkt, weil es nie einen Fehler gab. Es saß einfach da, tat nichts, verbrauchte null Ressourcen, sorgte für Verwirrung bei jedem, der den Flow zu lesen versuchte.

(Das ist das wiederkehrende Thema hier. Das gefährliche Zeug in n8n fällt nicht laut aus. Es fällt aus, indem es überhaupt nichts tut.)

Die Notiz braucht eine Auffrischung, wenn der Workflow sich ändert. Also habe ich Re-Dokumentation in den Prozess eingebacken: jedes Mal, wenn Claude Code einen Workflow modifiziert, aktualisiert es die Notiz. Nicht als separate Aufgabe. Als Teil des Commits.

Dokumentation dient zweimal: einmal für den Menschen, der das Projekt erbt, einmal für die KI, die darauf zurückkommt.

Drei Schichten gestapelt. Hier ist, wie es im großen Maßstab aussieht.

Die echte Lücke sind nicht Features. Es ist Wartung.

Ich fahre dieses Setup über alle meine Client-Instanzen. Dutzende von Workflows, hunderte von Nodes.

Alle reden über n8n-Templates, neue Integrationen, den AI Workflow Builder. Niemand redet darüber, was sechs Monate nach Deployment passiert. Die Lücke zwischen n8n Cloud und self-hosted geht nicht um Features. Es geht um Wartung. n8n hat massive Adoption und eine riesige Community, aber Workflow-Versioning bleibt hinter der Enterprise-Paywall. Dieses Verhältnis (Adoption vs Wartungs-Tooling) sagt dir genau, wo sich der Druck aufbaut.

Und ich bin nicht der Einzige, der das bemerkt. Self-hosted User nennen n8n-Wartung immer wieder ein Kopfzerbrechen. Leute wenden sich an Claude Code, um zu automatisieren, was n8n nicht out of the box liefert. Claude Code ist zur DevOps-Schicht geworden, die n8n self-hosted nicht mitbringt.

Dieses Setup braucht Claude Code, n8n-mcp und Git. Das ist echte Setup-Zeit im Voraus. Wenn du zwei oder drei einfache Workflows fährst, ist der manuelle Ansatz immer noch ok. Aber sobald du über zehn Workflows oder über hundert Nodes hinaus bist, ändert sich die Mathematik schnell.

Claude Code wurde zur DevOps, die n8n self-hosted nicht mitliefert.

---

Ich habe n8n Node-Wartung monatelang ignoriert, weil das Tooling einfach nicht existierte. An dem Tag, als ich hinschaute, fand ich Parameter, die stillschweigend verschluckt wurden, Versionen, die seit Workflow-Erstellung eingefroren waren, und null Spur davon, was sich geändert hatte. 🫠

Jetzt gefixt. Drei Schichten: Git für das Sicherheitsnetz, jq für die Chirurgie, Claude Code für die Dokumentation. Das Problem ging von "fass das nicht an" zu "ein Befehl pro VPS." Ich habe es nicht weiter getrieben, aber ich könnte einen automatischen Update-Check nach jedem n8n-Versions-Bump verdrahten.

n8n ist ein brillantes Tool zum Bauen von Workflows. Aber Bauen und Warten sind zwei verschiedene Jobs. Wenn du n8n self-hosted in Production fährst, ist die Frage nicht "sind deine Nodes veraltet."

Es ist, wie lange sie schon veraltet sind.

---

Quellen: n8n node versioning documentation | n8n-mcp on GitHub

(*) Das Cover ist AI-generiert. Die Nodes wollten ein Gruppenfoto, aber 27 von ihnen tauchten im Outfit der letzten Saison auf.