Node.js 26 wird LTS und lässt Zeit für den Wechsel von 24

Eilig ist der Wechsel nicht: Node.js 24 wird laut Release-Plan bis zum 30.04.2028 unterstützt, Node.js 22 bis zum 30.04.2027. Node.js 26 ist seit Version 26.13.0 vom 28.10.2026 Long Term Support (LTS) mit dem Codenamen „Lithium“ und soll Updates bis Ende April 2029 erhalten. Gegenüber 26.12.1 ändert das Release nur Metadaten.

Betroffen sind alle, die Node.js auf Servern betreiben. Wer noch Node.js 22 einsetzt, hat bis zum Ende des Supports etwa sechs Monate, bei Node.js 24 sind es rund 18. Dass eine Linie LTS wird, ist allein noch kein Grund zur Migration. Es markiert den Zeitpunkt, ab dem sich die Linie für den Produktivbetrieb auf lange Sicht eignet und ein geplanter Umstieg sinnvoll wird.

Was 26.13.0 tatsächlich ändert

Richard Lau schreibt in den Release Notes zu Version 26.13.0, das Release markiere den Übergang von Node.js 26.x in den Long Term Support mit dem Codenamen „Lithium“. Die Linie werde weiter Updates bis Ende April 2029 erhalten. Der GitHub-Eintrag zum Release trägt dieselbe Ankündigung.

Technisch ist 26.13.0 ein Statuswechsel. Außer Metadaten wie dem Objekt process.release unterscheidet sich der Code nicht von 26.12.1. Das Objekt process.release beschreibt zur Laufzeit, um welche Veröffentlichung es sich handelt, und enthält unter anderem den LTS-Codenamen. Anwendungen, die darauf nicht prüfen, merken vom Wechsel nichts.

Für den Betrieb heißt das: Wer bereits 26.12.1 getestet hat, muss für 26.13.0 keine neue Funktionsprüfung einplanen. Die Tests gelten für den Code, nicht für das Etikett.

dm-Einordnung: Im Alltag zählen andere Kriterien. Erstens die Restlaufzeit der eingesetzten Linie: Solange sie Sicherheitsupdates erhält, entsteht kein akuter Druck, und der Umstieg lässt sich planen statt erzwingen. Zweitens die Abhängigkeiten: Bibliotheken, native Module und Build-Werkzeuge müssen mit der neuen Linie laufen, und diese Prüfung kostet oft mehr Zeit als der Wechsel selbst. Drittens das Wartungsfenster: Ein Umstieg gehört in einen Zeitraum, in dem Zeit für Fehlersuche und Rückbau bleibt, nicht in eine Phase mit Releasedruck. Viertens der eigene Testaufwand: Je umfassender die automatisierten Tests sind, desto schneller und risikoärmer gelingt der Schritt. Wer diese vier Punkte nüchtern bewertet, trifft die Entscheidung auf belastbarer Grundlage und nicht allein anhand eines Etiketts.

Ein LTS-Release unterscheidet sich von einem Current-Release durch die Dauer der Pflege. Current-Linien erhalten neue Funktionen, aber nur kurz Updates. LTS-Linien werden nach dem Wechsel stabilisiert und über Jahre mit Korrekturen versorgt. Der Codename dient lediglich als Bezeichnung: 22 heißt Jod, 24 Krypton, 26 Lithium.

Wer Node.js 26 auch in Cloud-Funktionen im Blick hat: Node.js 26 in AWS Lambda tauchte zunächst als Vorschau-Runtime auf.

Die Support-Fenster von 22, 24 und 26

Die Node.js Release Working Group pflegt den Release-Plan im Repository nodejs/release. Er nennt für jede Linie vier Termine: Start der Active-LTS-Phase, Beginn der Maintenance, Ende des Supports (End-of-life, EOL) und bei neuen Linien das Erstveröffentlichungsdatum. In Active LTS fließen Korrekturen und ausgewählte Verbesserungen ein. In Maintenance gibt es nur noch kritische Fehlerbehebungen und Sicherheitsupdates. Der Plan weist selbst darauf hin: „Dates are subject to change.“

Node.js 22 „Jod“

Die Linie 22 war ab dem 29.10.2024 Active LTS und ist seit dem 21.10.2025 in Maintenance. Ihr EOL ist der 30.04.2027. Wer sie noch betreibt, hat laut Plan ab dem 30.10.2026 sechs Monate. Das ist die Linie mit dem knappsten Zeitfenster und der erste Kandidat für die Planung.

Node.js 24 „Krypton“

Node.js 24 war ab dem 28.10.2025 Active LTS. Nach dem Datum im Plan befindet sich die Linie seit dem 20.10.2026 in Maintenance, ihr EOL ist der 30.04.2028. Die Statusspalte der README zeigt 24.x teils noch als „Active LTS“, maßgeblich sind jedoch die Termine. Maintenance bedeutet nicht, dass die Linie unsicher wäre. Sie bekommt weiterhin kritische Fehlerbehebungen und Sicherheitsupdates, nur keine ergänzenden Verbesserungen mehr.

Node.js 26 „Lithium“

Node.js 26 erschien erstmals am 05.05.2026, wurde am 28.10.2026 Active LTS, wechselt am 20.10.2027 in Maintenance und endet am 30.04.2029. Node.js 20 „Iron“ ist bereits seit dem 30.04.2026 ohne Support. Wer diese Linie noch einsetzt, erhält keine Sicherheitsupdates mehr aus dem Projekt.

dm-Rechnung: Vom 30.10.2026 bis zum 30.04.2027 sind es 6 Monate (Node.js 22), bis zum 30.04.2028 sind es 18 Monate (Node.js 24), bis zum 30.04.2029 sind es 30 Monate (Node.js 26). Die Active-LTS-Phase von 26 dauert vom 28.10.2026 bis zum 20.10.2027, also knapp 12 Monate. Danach folgen rund 18 Monate Maintenance bis zum EOL.

dm-Einordnung: Auf Node.js 24 ist ein Umstieg in den nächsten Monaten möglich, aber nicht dringend, sofern die Anwendung läuft und Sicherheitsupdates eingespielt werden. Für 22 sollte bis spätestens Anfang 2027 ein Testlauf auf 24 oder 26 stehen, damit vor dem EOL genug Spielraum bleibt. Wer ohnehin einen Wechsel plant, springt besser direkt auf 26, weil dort die längste Restlaufzeit liegt.

libatomic und andere Stolpersteine beim Wechsel

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptRows of server cabinets in a data center with green and blue status lights, long corridor perspective, cool light. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Die Release Notes nennen für alle, die von einer früheren LTS-Linie wie 24, 22 oder älter kommen, einen konkreten Punkt: Seit Node.js 25 sind die offiziellen Linux-Binaries gegen libatomic gelinkt. Das kann je nach Distribution eine separate Installation erfordern. Wer also die offiziellen Linux-Binaries von Node.js 22 oder 24 betrieben hat, kann beim Start der neuen Version auf eine fehlende Bibliothek stoßen.

libatomic ist eine Laufzeitbibliothek, die atomare Operationen bereitstellt, also Speicherzugriffe, die ein Prozessor unteilbar ausführt. Programme brauchen sie, wenn der Compiler solche Operationen nicht selbst als einzelne Prozessorbefehle erzeugen kann. Dynamisch gelinkt heißt, dass die Bibliothek nicht in die Binärdatei eingebettet ist, sondern beim Start vom System geladen wird. Fehlt sie, startet das Programm nicht.

Praktisch betrifft das vor allem schlanke Container-Images und minimale Server-Installationen, in denen nur das Nötigste vorhanden ist. Auf ausgestatteten Systemen liegt die Bibliothek häufig schon bereit. Ob das bei Ihnen so ist, zeigt nur ein Testlauf auf dem Zielsystem, nicht der Blick auf die Entwicklungsmaschine.

dm-Einordnung: Zwei weitere Punkte gehören auf die Prüfliste. Erstens native Module, also Erweiterungen, die in C oder C++ geschrieben und gegen eine bestimmte Node.js-Version kompiliert werden. Sie sollten für die neue Linie neu gebaut werden, statt Binärdateien der alten Version weiterzuverwenden. Zweitens die Frage, woher Node.js stammt. Offizielle Binaries folgen dem Release-Plan unmittelbar, Distributionspakete haben eigene Pflegezyklen und Versionsstände. Welche Linie Ihre Distribution anbietet und wie lange sie diese pflegt, muss deshalb separat geprüft werden. Dazu gehören auch die Sicherheitskorrekturen, die in dieser Phase weiterhin eingespielt werden, wie etwa die Node.js-Sicherheitspatches rund um Brotli zeigten.

Wer Node.js über ein Distributionspaket und über ein offizielles Binary gleichzeitig installiert hat, sollte den tatsächlich genutzten Pfad kennen. Sonst läuft nach dem Umstieg womöglich weiter die alte Version, obwohl die neue installiert ist.

Testen vor dem Wechsel und der neue Plan ab 27

dm-Einordnung: Ein sinnvoller Ablauf beginnt mit einer Staging-Umgebung, die dem Produktivsystem in Distribution, Bibliotheken und Container-Basis entspricht. Dort laufen die vorhandene Testsuite, ein Start der Dienste und ein Lasttest mit realistischen Abläufen. Danach folgen die Abhängigkeiten: Native Module werden neu gebaut, und die Protokolle der ersten Tage zeigen, ob Warnungen auftreten. Weil 26.13.0 sich von 26.12.1 nur in Metadaten unterscheidet, gelten Ergebnisse mit 26.12.1 weiter.

Ein gestufter Rollout begrenzt das Risiko. Zuerst wechselt ein unkritischer Dienst, dann folgen die übrigen, und für jeden Schritt bleibt der Rückweg auf Node.js 24 offen. Dank des Support-Fensters bis 30.04.2028 ist dieser Rückweg ohne Zeitdruck möglich. Das ist der eigentliche Vorteil des späten Wechsels: Er lässt sich nach den Anforderungen der Anwendung planen, nicht nach dem Kalender.

dm-Einordnung: Nach dem Wechsel lohnt sich eine kurze, gezielte Kontrolle. Zuerst sollte feststehen, dass tatsächlich die erwartete Version läuft; dazu dient die Angabe der laufenden Version samt den Metadaten im process.release-Objekt, die den LTS-Status mit dem Codenamen Lithium ausweisen. Danach gehört das Monitoring in den Blick: Fehlerquoten und Speicherverbrauch sollten mit den Werten vor dem Umstieg verglichen werden, damit Abweichungen früh auffallen. Schließlich sollte der Rückweg dokumentiert sein, also welche Version, welches Artefakt und welche Schritte zum vorherigen Stand führen. So bleibt der Wechsel jederzeit umkehrbar.

Für die Entscheidung ist außerdem der neue Release-Plan wichtig. Ab Node.js 27 durchläuft jede Linie eine Alpha-Phase, jede Linie wird LTS und bleibt 30 Monate in Active LTS, ohne anschließende Maintenance-Phase. Bis Node.js 26 gilt noch das bisherige Modell mit Maintenance.

Node.js 27 befindet sich seit dem 28.10.2026 in der Alpha-Phase. Laut Plan wird die Linie am 22.04.2027 Current, am 20.10.2027 LTS und erreicht ihr EOL am 30.04.2030. Alpha-Versionen und Current-Linien sind keine Grundlage für Produktivsysteme, sie dienen zum frühen Testen von Kompatibilität.

dm-Rechnung: Node.js 27 läuft laut Plan vom 20.10.2027 bis zum 30.04.2030 als LTS, also rund 30 Monate. Node.js 26 hat ab dem 20.10.2027 noch bis zum 30.04.2029 Maintenance, also etwa 18 Monate. Beide Linien überschneiden sich damit ab Oktober 2027, sodass auf 26 ein späterer Übergang auf 27 möglich bleibt, wenn der Betrieb es erfordert.