Node.js Release Schedule Change: What One Release a Year Means for Your Upgrade Plan
Node.js is dropping odd-numbered releases after version 26. Here is what the new Alpha channel and the 2027 LTS dates change for your upgrade calendar.
On this page 7 sections
Starting with Node.js 27, the project ships one major release a year instead of two. Every release becomes LTS, and a six-month Alpha channel replaces odd-numbered versions for early testing. Node.js 26 is the last release under the old model and enters LTS in October 2026.
This Node.js release schedule change is the biggest shift to the project's calendar in about ten years. It matters if you run production services on Node, maintain an npm package, or own the upgrade calendar for an engineering team. This guide covers the new dates, the reasoning, and a practical plan, so you know what to do and when.
What Is the Node.js Release Schedule Change?
The Node.js project is moving from two major releases per year to one, starting with version 27. Odd and even numbering goes away, and each April release is promoted to LTS in October. Version numbers will match the calendar year, so 27.0.0 arrives in 2027.
For ten years, the rhythm was fixed. An even-numbered release landed in April and became LTS that October. An odd-numbered release landed in October and lived for only a few months. That pattern came out of the io.js merger, and it was designed around how companies adopted software a decade ago.
The new model removes the second release. In its place, the project adds an Alpha phase that runs from October to March, followed by a Current phase from April to October. After that, the release is promoted to LTS. The Node.js team described the plan in its official announcement, Evolving the Node.js Release Schedule, and it notes that the schedule is not final and may still be amended.
Backtrace covers JavaScript runtimes and build tooling for working engineers, and this is one of the few announcements that changes a calendar rather than an API. Nothing in your code breaks. What changes is when you get new features and how early you can test them.
Node.js 26 and 27 Dates at a Glance
The table below lists the confirmed dates for the last release under the old schedule and the first under the new one. Use it as the starting point for your own upgrade calendar.
| Milestone | Node.js 26 | Node.js 27 |
|---|---|---|
| Alpha begins | Not applicable | October 2026 |
| First stable release | April 2026 | April 2027 |
| Enters LTS | October 2026 | October 2027 |
| Maintenance begins | October 2027 | Set later |
| End of life | April 2029 | April 2030 |
Notice how little the support window moves. LTS still lasts 30 months, and total support runs 36 months from the first Current release to end of life. Teams that only run LTS builds will see mostly a naming change.
One detail trips people up. Node.js 26 is an even-numbered release, so it already follows the old LTS path. You do not need to wait for Node.js 27 to benefit from the new thinking. If you are on Node.js 22 or 24, Node.js 26 is the natural next step once it reaches LTS this month.
Why Did Node.js Drop Odd-Numbered Releases?
Odd-numbered releases saw very little production use, yet they still cost maintainers real time. Many organizations skipped them entirely and waited for LTS. The project is largely volunteer-run, so cutting one release line reduces backporting work and security patch duties.
The official announcement gives four reasons. The old schedule is ten years old. Odd releases have minimal adoption. The odd/even distinction confuses newcomers. And keeping four or five active release lines secure is hard for a volunteer project.
A June 2026 report from InfoQ on the Node.js release changes adds some history. A TSC member proposed the change in July 2025, citing the burden of backporting fixes across several lines. Another contributor noted that the original plan was built around corporate adoption cycles that nobody had revisited.
There is a real counterpoint. The same report says enterprises favor long support windows, while frequent upgraders want faster access to new features. One large-company user warned that a new LTS only once a year could feel slow. The 30-month LTS window is meant to calm that worry, and the overlap between LTS lines is preserved so migrations stay manageable.
How Does the Node.js Alpha Channel Work?
The Alpha channel is a six-month early-testing phase that runs from October to March before each stable release. Builds are signed, tagged, and tested against major open-source packages. They carry prerelease tags like 27.0.0-alpha.1. Semver-major changes are allowed, so they are not for production.
Alpha takes over the role odd-numbered releases used to play. Library authors could test against an odd release and report bugs before the next LTS shipped. Now they test against Alpha instead.
The testing behind Alpha is real. The project runs CITGM, short for Canary in the Goldmine, which executes the test suites of major open-source packages against the upcoming version. That is different from a nightly build, which is an untested automated snapshot of the main branch. An Alpha may also leave out some changes that sit on main.
The timing is flexible. The Release Team decides when each Alpha ships, so you should not expect a fixed weekly drop. The project also says the latest releases will still ship a V8 engine version that is at most about six months old, so new JavaScript features keep arriving on a steady pace.
If you maintain a library, this is the part to act on. Add a CI job that installs the newest Alpha and runs your tests. A failure in October is a quick fix. The same failure in April, after the release is out, becomes an issue thread from your users.
How Does This Affect Library Authors and Package Maintainers?
Package maintainers feel this change more than application teams do. Until now, a library could declare support for the two or three newest LTS lines and quietly ignore the odd releases. That shortcut still works, but the test matrix gets simpler and the early warning gets weaker.
With one release a year, your supported-versions list shrinks. A typical matrix might cover the active LTS line, the maintenance line, and the newest Alpha or Current build. Three jobs is a modest cost, and it catches breakage while the runtime team can still change course.
The official guidance is blunt on this point. The project recommends that library authors integrate Alpha into CI as early as possible. InfoQ makes the same case from the other side: if everyone tests only on LTS builds, bugs go unreported until they reach real users.
Pay attention to your engines field as well. Many packages declare a minimum Node version and never revisit it. When Node.js 26 reaches LTS, check whether your minimum still matches a line that receives security fixes, and raise it on your next major release if it does not.
What Should Your Team Do Before October 2027?
Treat the next twelve months as a staged plan. Node.js 26 is the first target, and Node.js 27 Alpha is the second. The steps below run in order, and the first two are cheap enough to start this week.
- Audit every place Node is pinned: Dockerfiles,
.nvmrcfiles, CI images, and serverless runtime settings. - Move any service on a non-LTS or soon-to-expire line onto Node.js 26 once it reaches LTS.
- Add a non-blocking CI job that runs your test suite on the newest Alpha.
- Read the changelog for removed APIs before the added ones, and fix deprecation warnings early.
- Schedule the Node.js 27 move for after its LTS date in October 2027, not its April release.
Start with the audit, because pinned versions hide in odd places. A base image tag in one forgotten service is how a team ends up running a line that has reached end of life. Our editors have seen more upgrade pain from forgotten pins than from any breaking API change.
Your package manager deserves a look too. Faster installs make Alpha testing cheaper in CI, and our npm vs. pnpm vs. Bun install speed comparison shows how much time a lockfile-aware cache can save. If you are also planning a Python move, the Python 3.15 upgrade checklist uses the same changelog-first habit.
Security teams should note one more thing. A predictable yearly LTS date makes patch planning easier, but it also means a longer gap between feature releases. If you rely on GitHub Actions to run Alpha builds, lock down your workflows first, and our guide on checking repos for the GhostAction workflow walks through that hardening step.
What if you cannot move quickly? That is fine. The 30-month LTS window gives you real room, and Node.js 26 stays supported until April 2029. The goal is to avoid a forced, rushed upgrade, not to chase every release.
Conclusion
The practical answer is simple. If you only run LTS, nothing urgent changes, and Node.js 26 is your next stop. If you maintain packages, start testing on Alpha in October 2026.
Your next step is the pin audit. Spend an hour finding every Node version in your repos and write the end-of-life date beside each one. Backtrace will keep tracking the Node.js release schedule change as the project finalizes the Alpha process, so check back before your next planning cycle.
