From Node.js 27, the project moves to one major release per year, and every major version reaches LTS after six months as Current. The old even and odd split ends. For teams, the main change is fewer lines to track and a yearly upgrade rhythm.
What the project says
The Node.js releases page states two models. Through Node.js 26, odd numbered releases become unsupported after six months, while even numbered ones move to Active LTS. Starting with Node.js 27, releases become annual, and each major spends six months as Current and then moves to LTS. The page also mentions "six additional months of Alpha phase" without defining it.
I could not confirm from the page what the Alpha phase does, or whether the 30 month LTS guarantee stays the same. Check the Release working group repository before you build a plan on either detail.
What the schedule file shows
The Release working group schedule file lists line 27 with a start date of 2027-04-22, a maintenance date of 2027-10-20 and an end date of 2030-04-30. It gives no LTS date for 27 in the version I read, and it lists an alpha date of 2026-10-28.
Treat those as the current plan, not a promise. Schedules for unreleased lines move.
Old model versus new model
| Through Node.js 26 | From Node.js 27 | |
|---|---|---|
| Majors per year | Two | One |
| Which reach LTS | Even numbers only | All |
| Odd lines | About six months of support | No longer exist |
| Typical LTS guarantee | About 30 months | Not restated on the page |
What to do about it
- Stop planning around odd and even. If your rule today is "skip odd versions," it will need to change after 26.
- Plan a yearly upgrade slot. One major a year gives you a predictable window. Put it on the calendar, for example a month after the line reaches LTS.
- Keep the upgrade small. Teams that upgrade every year face fewer removals per step than teams that upgrade every three years.
- Watch the support length. If the LTS guarantee changes, your calendar changes with it.
What does not change
Security still depends on running a supported line and applying patches. A yearly cadence helps only if the upgrade actually happens. Services that sit on a line until end of life are still the real risk, whatever the schedule.
Try it yourself
The gate pull request demo shows a policy check blocking a change in review. A common use after a runtime move is a gate that stops a pull request which reintroduces an old base image.
Click through it at your own pace, or open it full screen.
Safeguard supports policies and gates on pull requests, so a team can encode its chosen runtime baseline as a check. The free scan is at gold.safeguard.sh/scan.
Quick check
Will Node.js 26 be the last line with an odd and even split?
Per the releases page, the split applies through Node.js 26 and the annual model begins with 27.
Is the Node.js 27 schedule final?
No. It is a published plan. Re-check the schedule file before committing dates to a roadmap.
Related: How long is a Node.js LTS release supported.
Sources
Last reviewed: 19 October 2026.
