- Node 18 ist seit 30. April 2025 ohne Sicherheitsupdates, Node 20 seit 30. April 2026. Wer darauf produktiv läuft, bekommt für neu entdeckte Lücken keine Patches mehr.
- Aktuell unterstützt sind nur Node 22 (Wartungsmodus bis April 2027) und Node 24 (aktive LTS bis April 2028). Node 26 wird am 28. Oktober 2026 selbst zur neuen LTS-Version.
- Der sichere Weg ist ein schrittweises Upgrade über die Zwischenversionen mit Tests nach jedem Schritt, nicht ein Sprung von der alten direkt auf die neueste Version.
- KI-Coding-Werkzeuge beschleunigen die mechanische Arbeit. Die Entscheidung über Risiko, Testtiefe und Rollback bleibt bei Menschen mit Kontext über das eigene System.
1. Warum ein Node.js-Upgrade jetzt zur Terminsache wird
Node.js folgt seit Jahren dem gleichen Rhythmus. Jede gerade Hauptversion, 18, 20, 22, 24, 26, wird zur Long-Term-Support-Version, sobald die nächste Zwischenversion erscheint, in der Regel im Oktober. Ab diesem Moment läuft die Uhr: 12 Monate aktive LTS mit neuen Fixes und Verbesserungen, danach 18 Monate reine Wartung, in der nur noch kritische Bugs und Sicherheitslücken geschlossen werden. Nach insgesamt 30 Monaten endet der Support vollständig.
Für die Praxis heißt das im September 2026: Node 18 ist seit 30. April 2025 ohne jeden Support, Node 20 seit 30. April 2026. Aktiv unterstützt sind nur noch Node 22, im Wartungsmodus bis April 2027, und Node 24, aktive LTS bis Herbst 2026 und danach Wartung bis April 2028. Node 26 läuft seit Mai 2026 als Current-Version und wird am 28. Oktober 2026 selbst zur neuen LTS-Version.
Der Support-Kalender im Überblick
| Version | Status (Herbst 2026) | Support bis |
|---|---|---|
| 18 (Hydrogen) | End of Life seit 30.04.2025 | kein Support mehr |
| 20 (Iron) | End of Life seit 30.04.2026 | kein Support mehr |
| 22 (Jod) | Maintenance LTS | 30.04.2027 |
| 24 (Krypton) | Active LTS, ab Herbst 2026 Maintenance | 30.04.2028 |
| 26 | Current, wird LTS am 28.10.2026 | 30.04.2029 |
2. Was passiert, wenn Sie auf einer End-of-Life-Version bleiben
End of Life heißt nicht, dass eine Anwendung an einem Stichtag aufhört zu laufen. Sie läuft weiter, bis eine von drei Bruchstellen zuschlägt: eine Sicherheitslücke, eine Abhängigkeit oder das Hosting.
Ohne Support patcht niemand mehr bekannt werdende Schwachstellen in der Node.js-Runtime selbst, etwa in der eingebauten OpenSSL- oder V8-Version. Für Unternehmen, die unter den Cyber Resilience Act fallen, kommt eine zweite Ebene dazu: Seit 11. September 2026 gilt eine Meldepflicht für aktiv ausgenutzte Schwachstellen, mehr dazu im Beitrag zum Cyber Resilience Act. Eine Lücke lässt sich schwer melden und beheben, wenn der Hersteller der Runtime längst keine Patches mehr liefert.
Parallel dazu verlangen neue Versionen gängiger npm-Pakete in ihrem engines-Feld zunehmend eine aktuelle Node-Version. Wer auf Node 18 bleibt, verliert nach und nach die Möglichkeit, Abhängigkeiten zu aktualisieren, ohne dass der Node-Unterbau bricht. Das ist genau der Mechanismus, der aus einer einzelnen veralteten Laufzeitversion technische Schulden im großen Stil macht: Jede aufgeschobene Aktualisierung erschwert die nächste.
Der dritte Bruchpunkt ist das Hosting. PaaS-Anbieter und Cloud-Runtimes entfernen End-of-Life-Versionen aus ihren Images, oft ohne große Ankündigung. Ein Deployment, das gestern lief, findet dann keine passende Runtime mehr, und das Upgrade wird zum ungeplanten Notfall statt zum geplanten Projekt.
Praxis-Hinweis: Prüfen Sie zuerst das engines-Feld in Ihrer package.json und in den drei bis fünf wichtigsten Abhängigkeiten. Verlangt eine davon bereits eine neuere Node-Version, als auf der Sie produktiv laufen, ist das Upgrade schon überfällig, auch wenn die Anwendung noch fehlerfrei läuft.
3. Die Inventur vor dem Upgrade
Ein Node.js-Upgrade beginnt nicht beim Installieren der neuen Version, sondern beim Wissen darüber, was von der alten abhängt. Vier Punkte gehören in diese Inventur:
- Node-Version im engines-Feld von
package.jsonund in der CI/CD-Konfiguration. - Alle Abhängigkeiten und deren Node-Kompatibilität,
npm outdatedundnpm lszeigen den aktuellen Stand. - Native Module mit kompilierten Bindings, etwa für Datenbanktreiber oder Bildverarbeitung. Sie müssen bei jedem größeren Versionssprung neu gebaut werden, weil sich die interne Modul-Schnittstelle ändert.
- Test-Abdeckung der Pfade, die beim Upgrade am ehesten brechen: Datei-Zugriffe, Kryptografie, alles, was direkt mit der Runtime statt mit einem Framework spricht.
Bei gewachsenen Anwendungen ist der letzte Punkt oft der schwierigste, weil diese Pfade selten dokumentiert sind und die Person, die sie ursprünglich geschrieben hat, das Unternehmen längst verlassen haben kann. Wenn intern die Kapazität für diese Bestandsaufnahme fehlt, lässt sie sich als punktuelles Projekt im Rahmen einer externen Softwareentwicklung abwickeln, ohne das eigene Team von seiner Roadmap abzuziehen.
4. Schrittweise upgraden statt in einem Sprung
Der naheliegende Impuls, direkt von Node 18 auf die aktuelle Version zu springen, ist bei gewachsenen Anwendungen der teurere Weg. Jede übersprungene Hauptversion bringt eigene Breaking Changes mit, und wenn mehrere davon gleichzeitig auftreten, lässt sich ein Fehler kaum noch der richtigen Ursache zuordnen.
Der sicherere Weg geht über die Zwischenversionen: von 18 auf 20, von 20 auf 22, von 22 auf 24, jeweils mit vollständigem Testlauf, bevor der nächste Schritt beginnt. Das dauert insgesamt länger, aber jeder einzelne Schritt bleibt klein genug, um ihn im Fehlerfall zu verstehen und zurückzurollen.
Ein Rollback-Pfad gehört vor den ersten Schritt, nicht danach. In der Praxis heißt das: ein gepinntes Docker-Image oder eine dokumentierte Vorgänger-Version der Runtime, ein Deployment-Mechanismus, der in Minuten statt Stunden zurückspielt, und eine Staging-Umgebung, die dieselbe Node-Version wie die geplante Produktivumgebung fährt, nicht die alte.
Wer diesen Plan nicht nebenbei im laufenden Betrieb mitlaufen lassen will, sondern als eigenständiges Vorhaben mit klarer Verantwortung, findet in einem Interim-CTO auf Zeit die Person, die genau das über mehrere Sprints hinweg verantwortet.
5. Wo KI-Coding-Werkzeuge helfen, und wo nicht
KI-Coding-Agenten sind für genau die Art von Arbeit gebaut, die ein Node-Upgrade in großen Mengen produziert: mechanische, wiederkehrende Änderungen über viele Dateien hinweg. Veraltete API-Aufrufe ersetzen, Abhängigkeitsversionen anheben, Changelogs mehrerer Pakete zusammenfassen, das sind Aufgaben, bei denen ein Agent Stunden in Minuten verwandelt.
Die Grenze verläuft dort, wo Urteilsvermögen über die eigene Anwendung gefragt ist. Ob eine Warnung im Test-Log ein echtes Risiko oder Rauschen ist, ob ein bestimmter Pfad im Code geschäftskritisch genug ist, um ihn manuell statt automatisiert zu prüfen, und wann ein Rollback ausgelöst wird, das sind Entscheidungen, die Kontext über das eigene Geschäft brauchen, den kein Agent hat. Im Beitrag zu KI-Coding-Agenten im Unternehmen steht ein Muster, das sich hier wiederholt: Agenten sind stark im Happy Path und schwach bei Edge Cases, und ein Node-Upgrade besteht zu einem guten Teil aus Edge Cases.
Besonders für Unternehmen mit eigenem SaaS-Produkt zählt dieser Unterschied doppelt, weil ein Fehler beim Upgrade nicht die eigene Infrastruktur trifft, sondern die Kunden direkt, meist ohne Vorwarnung.
Fazit
Ein Node.js-Upgrade ist selten das Problem, unbemerktes Verschieben ist es. Node 18 und Node 20 laufen bereits ohne Support, und mit jedem Monat, den eine Anwendung darauf weiterläuft, wächst der Abstand zur aktuellen LTS-Version und damit der Aufwand für den irgendwann fälligen Sprung.
Wenn die Frage größer ist als nur die Node-Version, wenn also ohnehin ansteht, ob eine gewachsene Codebase vor einem Release, einer Due Diligence oder einer größeren Investition trägt, lohnt sich vorab die Codebase Decision: wenige Tage für eine klare Antwort, refactorn, neu bauen oder unverändert lassen, statt das im laufenden Betrieb herauszufinden.