On this page · 9 sections
Summary. For production workloads in 2027, Node.js 26 is the default choice. It became LTS (Lithium) on 28 October 2026, stays in Active LTS until 20 October 2027 and is supported until 30 April 2029. It ships V8 14.6, Undici 8 and the Temporal API enabled by default. Node.js 24 (Krypton) remains sound where 26 is not yet generally available. It moved to Maintenance LTS on 20 October 2026, so it now gets critical fixes and security updates only, and it ends on 30 April 2028. It runs V8 13.6 and is generally available on AWS Lambda, Azure Functions, Google Cloud Run functions and Vercel. Node.js 27 becomes Current on 22 April 2027 and LTS on 20 October 2027, with end of life on 30 April 2030. It is a test target until October 2027, not a production runtime. Platform support decides many cases: on 1 November 2026 Vercel runs 26 as its default, Lambda has 26 in public preview with general availability targeted for November 2026, Cloud Run functions lists 26 as Preview, and Azure Functions does not list it.
About this article. For engineering leads choosing a Node.js line for 2027. Features were checked on 1 November 2026 against nodejs.org release notes and the Node.js API documentation for each line, and platform support against AWS, Microsoft, Google Cloud and Vercel documentation. Node.js 27 details come from its first alpha and may change before 27.0.0. This is not legal advice, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.
If you are still on Node.js 22, read our Node.js 22 end-of-life migration guide first. For how the annual schedule works, see Node.js 27 and the one-major-a-year schedule.
Support windows side by side
The Release Working Group's schedule.json is the project's record of support claims, and the codename list covers lines not yet promoted. Latest releases come from the nodejs.org release index. The months-left row assumes a decision made on 1 May 2027, the day after Node.js 22 reaches end of life.
| Node.js 24 | Node.js 26 | Node.js 27 | |
|---|---|---|---|
| Codename | Krypton | Lithium | Magnesium (expected, may change) |
| First release | 6 May 2025 | 5 May 2026 | Alpha 28 Oct 2026; Current 22 Apr 2027 |
| LTS start | 28 Oct 2025 | 28 Oct 2026 | 20 Oct 2027 |
| Maintenance LTS start | 20 Oct 2026 | 20 Oct 2027 | None (Active LTS throughout) |
| End of life | 30 Apr 2028 | 30 Apr 2029 | 30 Apr 2030 |
| Phase on 1 May 2027 | Maintenance LTS | Active LTS | Current (not for production) |
| Months left on 1 May 2027 | 12 | 24 | 36 (30 from LTS) |
| Latest release on 1 Nov 2026 | 24.22.2 | 26.13.0 | 27.0.0-alpha.0.0.0 |
All 36 months of 27 count as supported, but the first six are the Current phase, and the project says production applications should use only LTS releases. Counting from its LTS promotion, 27 offers 30 months.
The Maintenance row matters more than it looks. In Maintenance LTS, a line receives critical bug fixes and security updates; new features land typically only when they help migration. Node.js 24 has been there since October 2026, so expect few features from 26.x minors to reach it. Node.js 27 changes this pattern: lines from 27 onwards stay in Active LTS for the full 30 months.
Feature comparison
These values come from the release notes for 24.0.0, 26.0.0 and the first 27 alpha, the API documentation and the release index.
| Feature | Node.js 24 | Node.js 26 | Node.js 27 (first alpha) |
|---|---|---|---|
| V8 engine | 13.6 | 14.6 | 15.6 |
| Headline JS additions | Float16Array, explicit resource management, RegExp.escape, Error.isError | Temporal on by default, Map.prototype.getOrInsert(), Iterator.concat() | Math.sumPrecise(), Iterator.zip(), Iterator.prototype.join() |
| Undici (built-in fetch) | 7 | 8 (8.0.2 at 26.0.0) | 8 (8.12.3 in the alpha notes) |
| npm | 11 | 11 | 12.1.0 |
| OpenSSL | 3.5 | 3.5 | 4.1.0 |
| TypeScript type stripping | On by default; stable from 24.12.0 | Stable | Stable |
| Transform-types flag | Available | Removed in 26.0.0 | Removed |
| require(esm) | Stable from 24.15.0 | Stable (since 25.4.0) | Stable |
| Permission model | Stable | Stable; adds network and FFI controls | Adds an environment variable permission |
| Default V8 heap limit | V8 default | V8 default | Half of RAM, clamped 256 MB to 4 GB |
| Addon ABI (NODE_MODULE_VERSION) | 137 | 147 | 153 (may change between alphas) |
| Notable platform change | macOS 13.5+ binaries; no armv7 binaries | Linux binaries link libatomic (since 25) | Intel macOS downgraded to experimental |
Built-in TypeScript type stripping
All three lines run .ts, .mts and .cts files directly by replacing type annotations with whitespace. No type checking happens, tsconfig.json is ignored, and only erasable syntax works. Enums, namespaces with runtime code, parameter properties and import aliases raise ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX. .tsx is unsupported, type-only imports need the type keyword, and Node.js refuses to handle TypeScript inside node_modules.
The difference is in the edges. The 24.x documentation marks type stripping stable from 24.12.0 and still offers --experimental-transform-types for enums and parameter properties. The 26.x documentation records that the flag was removed in 26.0.0, so on 26 any non-erasable syntax needs a compiler step or a third-party package such as tsx. The project recommends TypeScript 5.8 or newer with erasableSyntaxOnly and verbatimModuleSyntax enabled. Our earlier guide to Node.js native type stripping covers the tsconfig details.
If your codebase uses enums heavily, this single change can decide the version. Staying on 24 keeps the transform flag until April 2028; moving to 26 means replacing enums with as const objects or keeping a build step.
require(esm)
Loading ES modules with require() removes a long-standing source of dual-package pain. It came out from behind a flag in 22.12.0 and stopped warning in 22.13.0. The 26.x modules documentation marks it no longer experimental from 25.4.0, and the 24.x documentation records the same in 24.15.0. The limits are the same in both lines: the module graph must be synchronous, and top-level await throws ERR_REQUIRE_ASYNC_MODULE. --no-require-module switches it off if a dependency misbehaves, and process.features.require_module lets libraries detect it.
For 2027 the practical impact is that libraries can ship ESM-only builds and still serve CommonJS consumers on current 24.x and 26, so expect more packages to drop dual builds. Keep 24.x services on a recent minor, at least 24.15.0, to run the version where the feature is marked stable.
Permission model
The permission model has been stable since 22.13.0 and 23.5.0. On 24, running with --permission restricts file system access, child processes, worker threads, native addons, WASI and the inspector, which you then grant with flags such as --allow-fs-read and --allow-child-process. On 26 it also restricts network access and FFI, through --allow-net and --allow-ffi. --allow-net arrived in 25.0.0 and is still marked as active development. Both documents describe an audit mode (--permission-audit) that reports violations through diagnostics channels without blocking, and process.permission.drop() for giving up access after start-up. The 27 alpha adds --allow-env for environment variables.
The project is clear about the limits. The model is a seat belt for trusted code, not a sandbox, and it offers no guarantees against malicious code. Use it to stop accidents and narrow blast radius, and use containers, separate OS users or VM-level isolation for untrusted code. Our permission model hardening guide covers production flags.
V8 and the HTTP client
V8 versions track Chromium: 14.6 in Node.js 26 is part of Chromium 146. Each V8 jump brings new language features and, occasionally, changes to garbage collection and memory behaviour that show up in latency-sensitive services. The 27 alpha's V8 update carries more observable changes than usual: its notes list a new default heap limit, a serialisation format that older Node.js releases cannot read, last-bit differences in Math results and changes to error.stack lookup.
Undici, the library behind fetch, moves from 7 in Node.js 24 to 8 in Node.js 26. Vercel says this brings HTTP/2 by default for built-in fetch, and offers VERCEL_FETCH_DISABLE_H2=1 to keep HTTP/1.1 on its platform. If your services call internal APIs through proxies or load balancers with unusual HTTP/2 behaviour, test this path specifically.
Other differences worth checking
- Temporal is enabled by default only from 26. Our Temporal migration guide shows how to move off
Date.
- OpenSSL is 3.5 at security level 2 in Node.js 24. The 27 alpha moves to OpenSSL 4.1.0, removes the bundled FIPS provider build and ends OpenSSL engine support.
- Removed in 26:
http.Server.prototype.writeHeader()and the legacy_stream_*modules.module.register()is runtime-deprecated, which matters for custom loaders and can affect some APM agents.
Platform availability on 1 November 2026
Sources for this table are the AWS Lambda runtimes page and preview announcement, Microsoft's Azure Functions and App Service pages, the Cloud Run functions schedule and Vercel's version documentation.
| Platform | Node.js 24 | Node.js 26 | Node.js 27 |
|---|---|---|---|
| AWS Lambda | GA; deprecation 30 Apr 2028 | Public preview since Aug 2026; GA targeted Nov 2026 | Not announced |
| Azure Functions | GA; end of support 30 Apr 2028 | Not listed | Not listed |
| Azure App Service | Named target in the Node 22 retirement notice | Linux preview since 11 Sep 2026; no GA date found | Not announced |
| Google Cloud Run functions | GA; deprecation 30 Apr 2028, decommission 31 Oct 2028 | Preview | Not listed |
| Vercel | Available | GA and default since 29 Oct 2026 | Not listed |
| Self-managed containers | Available | Available | Alpha builds only until 22 Apr 2027 |
Lambda's preview runtimes carry no SLA or technical support, and AWS tied general availability to Node.js 26 reaching Active LTS, which it did on 28 October 2026. On Azure Functions, Linux Consumption apps cannot move past Node.js 22 without first migrating to the Flex Consumption plan. Our note on App Service and the Node 22 retirement covers that notice in detail.
Decision table
| Pick | If |
|---|---|
| Node.js 26 | Your platform runs it at GA and you want support to April 2029 with one migration |
| Node.js 26 | You want Temporal, Undici 8 and V8 14.6 without flags, and your TypeScript is erasable |
| Node.js 26 | You run your own containers or Kubernetes and control the base image |
| Node.js 24 | You deploy to Azure Functions, or Lambda before nodejs26.x reaches GA |
| Node.js 24 | Your TypeScript relies on enums or parameter properties at runtime and you are not ready to add a build step |
| Node.js 24 | Native addons, APM agents or vendor SDKs you depend on have not certified 26 |
| Node.js 27 | You publish libraries or SDKs and need to test against it from the alpha onwards |
| Node.js 27 | You plan to adopt it in production after 20 October 2027 and want early compatibility data |
If none of the rows applies cleanly, choose 26. The only strong reasons to start a new service on 24 in 2027 are platform availability and dependency certification, and both should shrink over the year.
Worked example: upgrade counts from 2027 to 2030
Take a team that must leave Node.js 22 by April 2027 and wants to stay on supported LTS lines through April 2030. Under the annual schedule, each line can only hand over to a line that is already LTS before it ends.
| Strategy | Moves | Count by Apr 2030 | Tightest window |
|---|---|---|---|
| A: 24 first | 22 to 24 (by Apr 2027); 24 to 27 (Oct 2027 to Apr 2028); 27 to 29 (Oct 2029 to Apr 2030) | 3 | 6 months each for the second and third moves |
| B: 26 first, biennial | 22 to 26 (by Apr 2027); 26 to 28 (Oct 2028 to Apr 2029) | 2, with 28 to 30 due by Apr 2031 | 6 months |
| C: 26 first, annual | 22 to 26 (by Apr 2027); 26 to 27 (Oct 2027); 27 to 28 (Oct 2028); 28 to 29 (Oct 2029) | 4 | 18 months of slack on every move |
Strategy A has a trap. Node.js 24 ends on 30 April 2028, so the newest LTS line available to it in time is 27 (LTS 20 October 2027). Node.js 28 only reaches LTS in October 2028, six months after 24 ends, so going from 24 straight to 28 leaves six months with either a Current release or no upstream support. Strategy B uses one fewer migration than A over the same period. Strategy C costs more upgrades but suits estates with slow change control, because a slipped quarter never reaches an end-of-life date. Dates for 28 and 29 come from the project's published ten-year timeline, which it says may be amended.
Migration notes
From 24 to 26. Expect V8 14.6 and Undici 8 behaviour changes, the removal of --experimental-transform-types, writeHeader() and the _stream_* modules, a runtime warning for module.register(), a new addon ABI (147) and libatomic on Linux for self-managed images. The 26.13.0 LTS notes flag the libatomic dependency for anyone updating from 24 or 22.
From 26 to 27 (after October 2027). Plan for the new heap default, the V8 serialisation format change (any persisted or cross-version structuredClone or v8.serialize data), OpenSSL 4.1 and the end of engine support, the domain deprecation and stricter HTTP header handling. Library authors should start testing on the alpha now, because the project warns that alpha APIs may still change and asks them to add alphas to CI early.
From 22. See our Node.js 22 guide, linked above, for the 22-to-24 breaking changes, including the rejection of short RSA and ECC keys at OpenSSL security level 2.
Compliance and regional notes
Version choice is also an audit question. Section 8(5) of India's DPDP Act 2023 requires reasonable security safeguards, and the Node.js project itself warns that many industry audits forbid unmaintained runtimes, so record the chosen line and its end-of-life date in your asset register. FIPS-bound workloads should test the 27 alpha early because of the bundled FIPS provider build removal. On Lambda, AWS says preview runtimes are available in all commercial, GovCloud (US) and China Regions, and that new Regions will not support runtimes due for deprecation within six months, which matters if you plan to expand into a new Region on Node.js 24 late in its life.
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. Our application development services team can help you pick a Node.js line, prove it against real workloads and roll it out in stages. Talk to us at /contact-us/.
Last updated: 2 November 2026.
