Hire Node.js developers in 2026: Node 20 is dead and the release model changes in October

Summary. Node.js 20 reached end of life on 30 April 2026, which is 110 days ago. Only three lines are supported today: Node 22 in maintenance until 30 April 2027, Node 24 in Active LTS until 30 April 2028, and Node 26 as Current, released 5 May 2026 and now at v26.7.0. The security release on 29 July 2026 patched 11 CVEs across v22.23.2, v24.18.1 and v26.5.1, three of them High. The OpenJS Foundation says "roughly two thirds of Node.js users are running outdated or unsupported versions". And from October 2026 the model itself changes: starting with 27.x, Node moves to one major release a year and every release becomes LTS. If you are about to hire Node.js developers, that combination is the brief. The work is not writing Express handlers. It is keeping a runtime inside a support window that is about to be redrawn.

What is actually supported right now

The release schedule in the nodejs/Release repository is the only source worth reading on this, and it is short.

Two things follow. First, a service on Node 20 today receives no fixes at all, and the July 2026 security post states the position bluntly: "It's important to note that End-of-Life versions are always affected when a security release occurs." Second, Node 22 is in maintenance, not Active LTS, so it gets security and critical fixes only. Teams that upgraded to 22 in 2024 and stopped are on a line with about eight months left.

The July 2026 release is a good measure of what patching actually involves. It shipped v22.23.2, v24.18.1 and v26.5.1 with 11 CVEs, including CVE-2026-56848, a heap use-after-free in HTTP/2 re-entrant send, and CVE-2026-58043, where the Permission Model's path matching could over-grant filesystem access. It also slipped twice: the project's own notes record delays on 27 July and 28 July "due to the need for additional testing and validation" and then "due to infrastructure issues". Patch windows are not a fixed date you can put in a change calendar. We covered that release in detail in our Node.js July 2026 security release playbook.

The release model changes from October 2026

The Node.js Releasers announced the change on the official blog, last updated 10 March 2026. The opening line is unambiguous: "Starting with 27.x, Node.js will move from two major releases per year to one."

The mechanics, in their words: "One major release per year (April), with LTS promotion in October", "Every release becomes LTS. No more odd/even distinction", and "Version numbers align with the calendar year of their initial Current release: 27.0.0 in 2027, 28.0.0 in 2028". The new phase table gives six months of alpha, six months as Current, 30 months of LTS, for "36 months from first Current release to End of Life". Node 27's alpha begins October 2026, 27.0.0 ships April 2027, LTS in October 2027, end of life April 2030. Node 26 "follows the existing schedule. This is the last release line under the current model."

The reason given is maintenance load, not developer convenience: "Managing security releases across four or five active release lines has become difficult to sustain. Each additional line increases backporting complexity." And, flatly, "Odd-numbered releases see minimal adoption."

For a hiring decision, this changes the shape of the job in one specific way. The odd-release skip trick stops working. Under the old model a cautious team ignored 21, 23 and 25 and moved every two years. Under the new one there is a single yearly train, everything is LTS, and the alpha channel exists precisely so that semver-major changes surface early. Someone has to be running your test suite against Node 27 alphas from October. We wrote up the cadence change on its own in our Node.js one release per year and Node 27 LTS upgrade guide.

Worth noting: the nodejs/Release README still describes the old six-month, odd-even model in its Release Plan section, and Node 27 appears in neither of its tables. Two official pages currently disagree. That is exactly the kind of thing a Node engineer should catch and a Node contractor working from a tutorial will not.

Node 26 broke things, and Node 27 will break more

Node 26.0.0 shipped 5 May 2026 with a set of removals that fail at require time rather than in a test. http.Server.prototype.writeHeader() "is now fully removed". The legacy _stream_wrap, _stream_readable, _stream_writable, _stream_duplex, _stream_transform and _stream_passthrough modules "are now fully removed". --experimental-transform-types is gone, module.register() is runtime-deprecated, and localStorage now returns undefined without a persistence file. The Temporal API is enabled by default, V8 moves to 14.6.202.33 and NODE_MODULE_VERSION becomes 147, which means every native addon has to be rebuilt.

Build floors moved too: GCC 13.2 minimum, Python 3.9 support dropped, Windows SDK 11, and by v26.7.0 the build requires rustc 1.86 or later. If your CI image was pinned in 2024, it will not build Node 26 at all.

There is also a mechanism most teams have never heard of, documented in the Node security release process: "Breaking changes are allowed in existing LTS lines in order to fix important security vulnerabilities." When that happens, Node ships a --security-revert=CVE-YYYY-NNNN flag to restore the old behaviour. Knowing that flag exists is the difference between a two-hour incident and a rolled-back patch.

The permission model is a seat belt, not a sandbox

The Permission Model, added in Node 20, is often sold to buyers as a security boundary. The Node documentation says otherwise, and the wording matters: "The permission model implements a 'seat belt' approach, which prevents trusted code from unintentionally changing files or using resources that access has not explicitly been granted to. It does not provide security guarantees in the presence of malicious code."

Three of the 11 CVEs in July 2026 were Permission Model issues: CVE-2026-58043 (High, path matching over-granting filesystem access), CVE-2026-56847 and CVE-2026-58039 (both Low, trace events and process reports writing outside the allowlist). Treat --allow-fs-read as defence in depth against your own bugs, not as a substitute for container isolation. Any candidate who describes it as a sandbox has read a blog post, not the docs.

One more piece of context that affects how patches reach you: on 2 April 2026 the project announced it had stopped offering bug bounties, stating "as a volunteer-driven open-source project, Node.js does not have an independent budget to sustain a bounty program on its own" and that "this decision was not made by the Node.js project". Reporting and triage continue unchanged, but the incentive to find issues upstream is weaker than it was.

The Lambda dates, and why the aggregators get them wrong

AWS publishes managed Node runtimes only after a line reaches LTS, and the current table reads:

Two corrections worth making, because both circulate widely. The nodejs20.x block dates are February and March 2027, not August and September 2026; AWS states it is "delaying the block-function-create and block-function-update dates beyond the usual 30 and 60 days after deprecation" for some runtimes "in response to customer feedback". And nodejs26.x is in public preview with a target launch of November 2026, described by AWS as "not covered by the Lambda SLA or Technical Support" and not for production.

What is true today is that nodejs20.x functions can no longer be created or updated through the Lambda console. The CLI, SAM and CloudFormation still work. That asymmetry is why teams discover the problem during an incident, when someone tries to hotfix in the console.

What this means for the hire

The distinction between this and project delivery matters, and it is why this page is separate from our Node.js development company page. Project work ends. Runtime ownership does not.

The OpenJS Foundation launched an LTS upgrade program in March 2026 for exactly this problem. Robin Bender Ginn, Executive Director of the OpenJS Foundation, said: "Many organizations depend on Node.js to run critical systems, but upgrading from older versions can be complex and risky. This program gives enterprises a clear, trusted path to modernize while staying aligned with the Node.js project and community." When the foundation that maintains the runtime builds a commercial programme around upgrades, that is a signal about where the effort actually sits.

So interview for it. Ask what NODE_MODULE_VERSION 147 means for a project with native addons. Ask what breaks when _stream_readable disappears. Ask what the Permission Model does not protect against. Ask what they would do the week Node 27 alphas start in October. None of that needs a code test.

India-specific considerations

For teams building in India, an unpatched runtime is now a legal exposure as well as an engineering one. The Digital Personal Data Protection Act 2023 puts breach handling on a legal footing, and the July 2026 CVE list includes HTTP parser header truncation enabling request smuggling (CVE-2026-58044) and an HTTPS Agent flaw that can skip hostname verification (CVE-2026-58040), both of which sit directly on the path user data travels.

Practically, the cheapest fix for most Indian product teams is not a bigger team. It is a named owner for the runtime, whether that comes from in-house capacity, staff augmentation services or a dedicated offshore product engineering team. What does not work is treating the upgrade as a ticket that gets bumped every sprint, because from October 2026 the train arrives annually whether or not anyone is on the platform.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. On Node.js work we take the jobs that get deferred: moving services off Node 20 and 22 onto the Active LTS line, rebuilding native addons across the NODE_MODULE_VERSION change, testing against Node 27 alphas from October, and migrating Lambda functions before the February 2027 create block. We staff that as embedded engineers or as a capped migration, and we will say which one your situation needs. Talk to us at /contact-us/.

References

1. Node.js Release Schedule - nodejs/Release repository

1. Evolving the Node.js Release Schedule - Node.js Releasers, updated 10 March 2026

1. Wednesday, July 29, 2026 Security Releases - Node.js

1. Node.js 26.0.0 (Current) - Rafael Gonzaga, 5 May 2026

1. Node.js 26.7.0 (Current) - Antoine du Hamel, 5 August 2026

1. Permissions - Node.js v26.7.0 documentation

1. Security release process - nodejs/node

1. Node.js LTS Upgrade Program - OpenJS Foundation, 4 March 2026

1. Discontinuing security bug bounties - The Node.js Project, 2 April 2026

1. Lambda runtimes - AWS Lambda Developer Guide

Last updated: 18 August 2026.