Node.js is changing how it ships versions, and your app is probably on an old one
Starting October 2026, Node.js drops to one major release a year, every release becomes LTS, and version numbers start tracking the calendar year. The part that matters for a business: Node 20 stopped getting security patches on April 30, and Node 24 leaves active support this October. Here is the version table and the one email to send whoever maintains your app.
There is a number attached to your website or web app that almost nobody looks at until something breaks: the version of Node.js it runs on.
Node.js is the runtime underneath most modern web applications. If your site was built in the last several years on Next.js, Astro, Remix, Nuxt, Express, or roughly anything else in that family, there is a Node version pinned somewhere in your project, and your hosting provider is running that version to serve your pages. It is invisible right up until it is a security problem or a failed deploy.
Node.js just changed how it ships those versions, and the change is worth ten minutes of your attention because it also makes a good excuse to check which version you are actually on. Two of the common ones are already out of support or close to it.
What changed
On March 10, 2026, the Node.js project announced it is moving from two major releases a year to one, effective October 2026. The specifics:
- One major release per year, landing each April instead of the old April-and-October pair.
- Every release becomes LTS (long-term support). The old split where odd-numbered versions were short-lived experiments and only even-numbered versions got long-term backing is gone.
- Version numbers now track the calendar year. Node 27 arrives in 2027, Node 28 in 2028, and so on. No more guessing which number is current.
- A new six-month alpha channel for early testing, starting October 2026, so library authors and CI pipelines can catch breaking changes before a release goes Current.
- The support window is unchanged at 30 months of LTS, or 36 months total from first release to end of life.
Node.js 26, which shipped this spring, is the last release under the old model. Node 27 begins its alpha in October 2026 and goes Current in April 2027.
The reason is maintainer capacity, not strategy. The proposal came from Node.js technical steering committee member Rafael Gonzaga in July 2025, and the argument was straightforward: the project was carrying several concurrent release lines, backporting fixes across all of them, and supporting odd-numbered versions that almost nobody adopted. That is a lot of volunteer effort spent on lines that were not doing much work.
Why this matters if you are paying for software, not writing it
The release schedule sounds like maintainer trivia. The support window underneath it is not, because it is the thing you are actually buying.
When a Node version reaches end of life, it stops receiving security patches. Not “patches slow down.” They stop. A vulnerability found in that runtime after its EOL date gets fixed in the supported versions and not in yours. Meanwhile hosting providers start refusing to run it, the packages your app depends on stop testing against it, and eventually a routine deploy fails for reasons nobody wants to debug on a Friday.
None of that happens on the day of the deadline. It accumulates over the following year, which is exactly why it gets ignored.
Here is where the common versions currently stand:
| Version | Status as of August 2026 | Security support ends |
|---|---|---|
| Node.js 20 | End of life | April 30, 2026 (passed) |
| Node.js 22 | Maintenance (security fixes only) | April 30, 2027 |
| Node.js 24 | Active LTS until October 20, 2026 | April 30, 2028 |
| Node.js 26 | Current, becomes LTS this October | April 30, 2029 |
Two things in that table are worth acting on.
If your app is on Node 20, it has been unsupported since April 30, 2026. That is not a future problem, it is a current one. Node 20 was the default choice for a lot of projects built in 2023 and 2024, so this catches more small business apps than you would expect.
If you are on Node 24, October 20 is when it leaves active support. Nothing breaks that day. It moves to maintenance, meaning security fixes only, no new features or performance work, through April 30, 2028. That is a perfectly reasonable place to sit for a while. It is just worth knowing you are sitting there deliberately rather than by accident.
What we do, and what we would tell you to do
Our own site is pinned to Node 24, which is Active LTS today and moves to maintenance in October. We will move it to Node 26 once 26 is promoted to LTS this fall, which is the pattern we recommend generally: run the most recent Active LTS, and upgrade in the autumn after the new line has settled.
That is the practical upside of the new schedule. Under the old two-a-year cadence, “keep up with Node” meant paying attention twice a year and mentally filtering out the odd-numbered releases that were never meant for production. Under the new one, it is a single annual calendar item, every release is a real LTS, and the version number tells you what year it came from. For a small team maintaining a handful of client applications, that is a genuine reduction in overhead.
Three rules that have not changed:
- Run an LTS release in production. Not the newest Current release, which is for library authors and early testing. Not an end-of-life release, for the reasons above.
- Do the upgrade before you are forced to. Moving from one LTS to the next is usually an afternoon. Moving off a version that has been dead for two years, on the day your host drops support for it, is not.
- Pin the version explicitly. In
package.json, in your hosting configuration, in your Dockerfile, wherever your stack expects it. A project that does not say which Node it wants will silently get whatever the host defaults to, and that default changes without asking you.
The one email to send
If you do nothing else with this post, send this to whoever maintains your website or app:
What version of Node.js is our application running in production, and when does it stop receiving security updates? If it is Node 20 or older, what would it take to move to a supported version?
The answer takes them about two minutes to look up. If the answer is Node 20 or older, you have found a real item for the next maintenance window. If it is 22, you have until April 2027 and can plan calmly. If it is 24 or 26, you are in good shape and you can file this away until next autumn.
The reason to ask now rather than later is that this class of work is cheap when it is scheduled and expensive when it is urgent. A runtime upgrade planned into a quiet week is a routine job. The same upgrade done in a hurry, because a vulnerability landed or a host pulled support, tends to arrive alongside dependency updates that were also deferred, and that is when an afternoon becomes a week.
If you are not sure what your site runs on, or the person who built it is no longer reachable, send us a note. Checking is free and takes us about as long as it takes you to ask.