Node.js 27 and one release a year: what about 22, 24 and 26

One major version a year, and every one gets LTS

For ten years Node.js shipped two major versions a year. The even-numbered version came out in April and became LTS in October. The odd-numbered version came out in October, lived for about 8 months and never got LTS. An LTS line had 12 months of active support and 18 months of Maintenance, during which it received mainly security and critical bug fixes.

From Node.js 27 on, the project ships one major version a year. Each line goes through this cycle:

• Alpha (October–March): test releases in the 27.0.0-alpha.1 format, signed and tested, but with breaking changes still allowed. Not intended for production.
• Current (April–October): the first stable version, a period for stabilisation.
• LTS (30 months): from October, with no split into Active and Maintenance.

36 months pass from the first Current release to end of support. There will be no more odd-numbered lines without LTS, and the version number matches the release year: 27.0.0 in 2027, 28.0.0 in 2028. The project published the new model in spring 2026 and notes that the dates may still change. It now takes effect in practice: on 28 October the Node.js 27 Alpha starts and Node.js 26 becomes LTS.

Dates for the lines you run today

• Node.js 22: in Maintenance since October 2025, end of support 30 April 2027.
• Node.js 24: in Maintenance since 20 October 2026, end of support 30 April 2028.
• Node.js 26: the last line under the old rules. LTS from 28 October 2026, Maintenance from 20 October 2027, end of support 30 April 2029.
• Node.js 27: Alpha from 28 October 2026, Current from 22 April 2027, LTS from 20 October 2027, end of support 30 April 2030.

Lines 22, 24 and 26 finish their cycle unchanged. The new rules apply from version 27 onwards.

Node.js 18 and 20 are now just risk

Node.js 18 lost support on 30 April 2025 and Node.js 20 on 30 April 2026. The odd-numbered lines 23 and 25 are unsupported too. These versions receive no fixes at all. The 21 October security release, which we cover in a separate post, shows this clearly: lines 22, 24 and 26 were patched, while 18 and 20 remain vulnerable. The Node.js project points out further consequences: popular packages gradually drop old versions, and compliance audits often explicitly forbid unsupported runtimes.

If migration cannot happen right away, the OpenJS Foundation lists paid support for EOL versions (HeroDevs, NodeSource, TuxCare). It is a temporary measure that buys time to move to a supported version.

Which version to move to now

• New deployments and applications on 18/20: target Node.js 26. It becomes LTS in a few days and is supported until April 2029.
• Applications on 22: half a year left. Plan the migration to 26 (or 24) for the coming months, with a margin before April 2027.
• Applications on 24: have until April 2028. Plan the move to 26 or 27 for 2027.
• Node.js 27 is not fit for production before April 2027. Alpha is for testing.

An upgrade calendar for the new rhythm

From 2027, a new LTS version arrives every October and is supported for 30 months. The simplest plan is one migration a year: between October and March you move to the newest LTS, once its first fixes have landed. Companies that upgrade less often can skip every other version, e.g. from 28 to 30. That leaves about 6 months for migration between the start of the new LTS and the end of the old one, so the date should be a fixed entry in your calendar.

Where to check which version you run

• Servers and workstations: node -v, and in projects the engines field in package.json plus .nvmrc and .node-version files.
• Docker images: grep -rn "FROM node" . across your repositories. Pin the major version (e.g. node:26-bookworm-slim) instead of node:latest or node:lts, because floating tags will switch the major version on the next build without your decision. After changing the base image, rebuild your images rather than just bumping the tag.
• CI: in test matrices (e.g. node-version in GitHub Actions) keep the supported LTS lines and remove 18 and 20. Teams maintaining their own libraries can add Alpha as a non-blocking job. The Node.js project explicitly recommends this so that bugs surface before the stable release.
• Vendor applications: Electron apps and some commercial products bundle their own Node.js, which you cannot update yourselves. Ask your vendors which line they are on and when they will move to a supported version.

What this means in the longer run

For companies that already install only LTS versions, the main changes are the numbering and the fact that a new LTS arrives once a year at a fixed time. A fixed date makes planning easier, but it requires an inventory: where Node.js runs, in which version and who is responsible for upgrading it. Companies with such an inventory handle every version change as a regular task in the annual plan instead of a rushed migration after the next security release.