Node.js Is Moving to One Release a Year. The People Who Ship It Explain Why.

HeroDevs' Javier Perez recently hosted a conversation with two people who spend their days inside the Node.js project. Matteo Collina is the chair of the Node.js Technical Steering Committee, the creator of Fastify and Pino, and the maintainer of undici, the library behind fetch. Across everything he maintains, his modules have been downloaded more than 42 billion times. Marco Ippolito is a member of the TSC who shipped roughly 70% of the Node.js 20 LTS releases, and who now provides vulnerability fixes to end-of-life versions as part of his work at HeroDevs.

The discussion covered a lot of ground. Here are the parts worth your attention.

One major release a year, starting with Node.js 27

Today, Node.js ships a major release every six months. Even-numbered versions become Long Term Support; odd-numbered versions do not. Starting in 2027, that changes. Node.js will move to one major release per year, with odd-numbered versions becoming LTS. Node.js 27, due in 2027, will be the first odd release to carry LTS status, and from there the version number will track the calendar year.

The reason is sustainability. Maintaining four release lines at once is too much work for a mostly volunteer team, and security releases are the hardest part. The lines also drift apart over time. Marco pointed out that Node.js 22 and Node.js 26 have diverged enough that backporting a single commit between them has become genuinely difficult.

The other reason is data. As Matteo put it, the non-LTS releases barely get used, so the effort to produce, test, and secure them is spent on almost no one. Teams that want to live on the edge will still have a long alpha channel for testing breaking changes early. The tradeoff is that those alphas come with no security guarantees.

The problem underneath: nobody upgrades

The schedule change is really a response to a deeper pattern. Most organizations do not upgrade Node.js after they deploy.

The numbers make the point. Node.js 20 reached end of life on April 30, 2026. In that same month, it was still downloaded around 95 million times. Even Node.js 16, which is years past end of life, is still pulled roughly 20 million times a month.

Marco's explanation is that teams fall so far behind in their dependency tree that upgrading stops being an incremental task and becomes a major refactor. At that point the work gets deferred again, and a six-month version they never adopted does nothing to help. Fewer, more stable major releases are meant to lower the bar to move.

Why the bounty program is on pause

The Node.js TSC recently paused its security bounty program. Worth clarifying up front: the reporting and triage process is unchanged. Reports still come in through HackerOne and are triaged by volunteers. What paused is the cash bounty, for two reasons.

The first is a flood of AI-generated, low-quality reports. Matteo described the economics bluntly: someone can spend a hundred dollars in tokens generating submissions and turn that into a thousand-dollar bounty, which makes low-effort reporting a money-making scheme rather than security research. The asymmetry is the core problem. Generating a report is nearly free, while triaging one costs real volunteer time to reproduce and verify.

The second reason is simpler. The bounty had lost its sponsor. Matteo, who also sits on the OpenJS Foundation board, said the foundation is now working with a group of vendors to fund a restructured program, likely scoped to high and critical vulnerabilities only, so the incentive rewards serious work instead of volume.

AI is also getting better at finding real bugs

Not every AI-assisted report is noise. The share of plausible submissions has climbed to roughly two-thirds, and real vulnerabilities are now coming in this way.

The genuinely new capability, both maintainers agreed, is chaining. An LLM can chain several individually low-severity issues into a working exploit, which is hard and slow for a human to do by hand. A handful of low or medium CVEs that look harmless in isolation can become critical when combined. What still decides whether a report has value is context and judgment, not the tool that produced it.

The hidden labor behind a single security release

Part of what makes Node.js security releases so demanding is the dependency chain underneath them. Node.js bundles its own HTTP parser, llhttp, and undici, the library that powers fetch and the newer web-standard APIs. Matteo maintains undici.

When a security fix touches undici, it has to ship across every active LTS line, each pinned to a different major version. Node.js 22 runs undici 6, Node.js 24 runs undici 7, and Node.js 26 runs undici 8, which means a single Node.js security event can require three separate undici releases, coordinated across multiple releasers inside a tight window.

Then there is testing. Node.js runs continuous integration against real packages pulled from the ecosystem, a test called the "canary in the gold mine," to catch breakage before it reaches users. Those runs take hours and rarely pass on the first attempt.

What happens after end of life

Marco also patches versions long past their official support window: Node.js 12, 14, 16, 18, and now 20. His observation from that work is that old versions are far less secure than most teams assume, and that new security fixes frequently turn out to apply to end-of-life versions too. As the project moves forward and finds new bugs, many of them trace back to code that has been sitting in production for years.

Once an LTS line ends, upstream patches stop. There are no more releases, no more fixes. Organizations that cannot migrate before that date need another source of security updates.

This is where HeroDevs fits. HeroDevs is a founding member of the OpenJS Foundation's ecosystem sustainability program and sponsors Marco's upstream release work on Node.js. For organizations still running end-of-life Node.js, Never-Ending Support for Node.js provides ongoing security patches and compliance coverage, including custom builds for teams that want to be ready before a version reaches its end-of-life date, so migration happens on your schedule rather than against a deadline.

Want the full conversation? Watch the webinar replay.