Node.js 27 release schedule: one major a year from 22 April 2027

Summary. Node.js 27.0.0 is scheduled for 22 April 2027 as the first release line on the annual model. The Release Working Group lists alpha from 28 October 2026, Current from 22 April 2027, LTS from 20 October 2027 and end of life on 30 April 2030. That is 30 months of LTS and 36 months from first Current release to end of life. Three things differ from earlier lines. Every major now becomes LTS, so the odd/even split ends with Node.js 26. New lines have no Maintenance phase. Version numbers follow the calendar year, so 28.0.0 is planned for April 2028. The first alpha, 27.0.0-alpha.0.0.0, appeared on 29 October 2026 with V8 15.6, OpenSSL 4.1 and npm 12.1.0, and it already changes the default heap limit and ends OpenSSL engine support. From 22 to 30 April 2027, four lines are supported at once (22, 24, 26 and 27). Production guidance does not change: run LTS, which in April 2027 means 26 or 24, and treat 27 as a test target until October. The planning rule is new: each line ends only six months after the line two versions newer reaches LTS, so skip at most one line between upgrades.

About this article. For engineering leads and platform teams planning Node.js upgrades. Dates were checked on 1 November 2026 against the Release Working Group schedule, the nodejs.org announcement and release notes, and AWS, Microsoft, Google Cloud and Vercel documentation. The project says its dates may change, and the 27.x feature list below comes from an alpha. This is not legal advice, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

We covered the announcement itself in July 2026 in our note on the one-release-a-year change. This piece covers what the release line looks like in practice, what is already in the alpha, and the planning arithmetic. If you are still on Node.js 22, start with our Node.js 22 end-of-life migration guide.

What happens on 22 April 2027

Node.js 27.0.0 moves from Alpha to Current. Under the Release Working Group's plan, each April the line that has been in alpha since October gets its first semver-major release and enters Current. It stays Current for six months, then moves to LTS in October through a semver-minor release. Nothing else on the calendar moves on 22 April, but the next eight days are unusual. The phases below follow the group's schedule.json.

For eight days the project supports four lines. On 1 May 2027 that drops to three. Node.js 26 remains the newest line suitable for production through the whole Current phase of 27, because the project says production applications should use only Active LTS or Maintenance LTS releases.

Version numbering also changes meaning. Under the old model, an odd number signalled a six-month line that most teams skipped. Node.js 27 is odd and will be LTS. Any internal policy, Renovate rule or base-image script that filters on even majors needs rewriting before 22 April, or it will silently ignore 27 for its entire life.

The phases, as the Release Working Group now defines them

The announcement, last updated on 10 March 2026, and the Release repository README define the phases. Release lines up to and including 26 keep the old rules; 27 onwards follow the new ones.

The Maintenance row is the quiet change. Node.js 24 and 26 still drop to Maintenance after 12 months of Active LTS, so their last 18 months carry security fixes and little else. Node.js 27 and later stay in Active LTS until end of life, so the Release team can keep backporting audited features for the whole 30 months. A late-life 27.x should therefore be more current than a late-life 24.x.

A few process rules matter for planning:

• Alpha releases are signed, tagged and tested through CITGM, the project's tool that runs the test suites of major open-source packages against upcoming releases. Nightly builds remain untested automated builds.

• Alpha cadence is flexible. The Release team decides timing and frequency based on the volume of changes. The first alpha used the version string 27.0.0-alpha.0.0.0, which differs from the 27.0.0-alpha.1 example in the announcement, so do not hard-code a prerelease pattern in tooling.

• Changes normally live in an Alpha or Current release for at least two weeks before they are backported to LTS lines.

• Phase dates are fixed no later than the first day of the month in which they change, and the team gives at least 14 days' notice of any change to a release date.

• Every LTS line gets a codename. Node.js 26 received Lithium at its LTS promotion on 28 October 2026. The project's list expects Magnesium for 27 and Neon for 28, and says future names may change.

What is already in the Node.js 27 alpha

The 27.0.0-alpha.0.0.0 release notes, dated 29 October 2026, show what the line is accumulating. Semver-major changes can still land until April, so treat this as a preview of the 27.0.0 changelog, not the final list.

• V8 15.6, up from 14.6 in Node.js 26. New defaults include Math.sumPrecise(), Iterator.zip(), Iterator.prototype.join() and Iterator.prototype.includes().

• Memory defaults change. Without --max-old-space-size, the heap limit becomes half of physical memory, clamped between 256 MB and 4 GB, and memory held by Buffer and ArrayBuffer now counts toward that limit. Containers that relied on the old default should set the flag explicitly.

• Serialisation format change. v8.serialize(), structuredClone() and postMessage() use a format older Node.js releases cannot read. Anything that persists or exchanges V8-serialised data between versions needs a plan.

• OpenSSL 4.1.0, with OpenSSL 3 or later required for builds, the bundled FIPS provider build removed and OpenSSL engine support ended. Teams that relied on the bundled FIPS build or on engines (for example, some hardware security module setups) should test early.

• Intel macOS downgraded to experimental. The first alpha still shipped an Intel macOS package, but expect weaker platform guarantees.

• npm 12.1.0 replaces npm 11.

• HTTP behaviour. The keepAliveTimeout default rises to 65 seconds, req.headers gets a null prototype, responses that exceed the header limit are rejected and HTTP/2 default window sizes increase.

• Deprecations and removals. The domain module is runtime-deprecated, the legacy _tls_* modules reach end of life, and the legacy AsyncLocalStorage implementation is removed.

• Additions. A new --allow-env permission for the permission model, an experimental net/promises API and a native fs glob implementation.

• Addon ABI. The notes move NODE_MODULE_VERSION to 153. The project warns that ABI can change between alphas, so treat that number as provisional.

The project's commitment on V8 is unchanged: latest releases will include a V8 version at most about six months old, and the alpha window lets V8 updates land earlier in the cycle.

Fewer lines to track, and why that matters

The announcement's main argument is sustainability. Node.js is maintained mostly by volunteers, and security releases across four or five active lines had become hard to sustain. The new model cuts the count.

Under the old model, four lines were often supported at once. In November 2025, for example, 20, 22, 24 and 25 were all supported. Once Node.js 26 ages out, the published timeline settles into three supported lines:

If later Aprils follow the 2027 pattern, a short overlap of four lines will recur each spring, when the new line enters Current just before the oldest line ends.

For your team, the practical effect is that one security release from the project usually means three builds to watch, not four or five, and each of those lines has a clear end date that falls in April.

Planning rule: skip at most one line

Here is the arithmetic the new model forces. Line N becomes Current in April of year Y, LTS in October of Y and reaches end of life in April of Y+3. Line N+2 becomes LTS in October of Y+2, six months before N ends. Line N+3 only becomes Current in April of Y+3, the same month N ends, and it does not reach LTS until six months later.

Dates for lines 28 to 31 come from the announcement's ten-year table, which the project says may be amended; schedule.json currently lists exact dates only up to 27. The conclusion is the same either way:

• Annual cadence (every line). Adopt each line at LTS in October and leave it 12 months later. You always run a line with at least 18 months of support left.

• Biennial cadence (every second line). Adopt N+2 at LTS and finish within six months. This halves the number of upgrades but leaves no slack: a slipped project means running an unsupported runtime.

• Skipping two lines (N to N+3) is only possible by running a Current release in production or accepting a period without upstream support. Neither belongs in a production policy.

For most product teams, the biennial cadence with a fixed October-to-March upgrade window is the efficient choice. Teams with many services or slow change control should run annually so that a slipped quarter is not a compliance event. Node.js 24 is a special case because line 25 never became LTS: it ends on 30 April 2028, so its last safe hops are to 26 or 27. Our comparison of Node.js 24, 26 and 27 works through those paths.

What platforms are likely to do with Node.js 27

The managed platforms tie their runtimes to the upstream LTS phase, which sets realistic expectations for 27.

• AWS Lambda says it provides managed runtimes for new language versions only when a release reaches LTS, and it lists November 2026 as the indicative launch month for Node.js 26. When it launched public preview runtimes in August 2026, it said it would not take Node.js 26 to general availability before Active LTS, and it called previews an experiment it hopes to make the default. Applied to 27, that policy implies a possible preview after 22 April 2027 and general availability no earlier than 20 October 2027.

• Vercel made Node.js 26 generally available and the default on 29 October 2026, one day after LTS promotion.

• Azure Functions listed only Node.js 22 and 24 on its supported languages page, last updated on 22 October 2026, so expect a lag after LTS.

• Google Cloud Run functions listed nodejs26 as Preview on its runtime schedule, last updated on 26 October 2026.

Our inference for planners: budget for Node.js 27 to be available as a supported managed runtime in the fourth quarter of 2027 at the earliest, and for some platforms in 2028. Container-based services can move sooner, since you control the image.

Setting your version policy for 2027 to 2030

A written policy beats a per-service debate. This is our suggested sketch, not project guidance:

Encode it in CI so it is enforced rather than remembered. This GitHub Actions matrix tests the two production lines and adds 27 as a non-blocking job after 22 April 2027:

            jobs:
  test:
    runs-on: ubuntu-latest
    continue-on-error: ${{ matrix.experimental }}
    strategy:
      fail-fast: false
      matrix:
        node: ['24', '26']
        experimental: [false]
        include:
          - node: '27'
            experimental: true
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci
      - run: npm test
          

Pair it with a pinned engines.node value such as 26.x. An open range is not safe: Vercel says a range that allows 26, such as >=20, moves the build to 26 on the next deployment. Pin container images to a major tag such as node:26-slim, not a floating lts tag, so the October promotion does not change a production image without review.

Key dates, 2026 to 2030

These dates come from schedule.json, the release notes and, for 28.0.0, the announcement's timeline.

Compliance and regional notes

For Indian teams, section 8(5) of the Digital Personal Data Protection Act 2023 requires data fiduciaries to take reasonable security safeguards, and an end-of-life runtime is difficult to defend once a fix exists upstream. The annual model helps here: end-of-life dates now fall in April every year, so they can sit in the same compliance calendar as certificate renewals and audit cycles. FIPS-bound workloads should track the alpha's removal of the bundled FIPS provider build. Our DPDP Act engineering playbook covers the broader controls.

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 turn the annual Node.js schedule into a working policy: version standards, CI matrices, golden container images and staged rollouts. Talk to us at /contact-us/.

Last updated: 1 November 2026.

References

1. schedule.json — Node.js Release Working Group

1. Release schedule, phases and release plan (README) — Node.js Release Working Group

1. Evolving the Node.js release schedule, last updated 10 March 2026 — Node.js

1. Node.js 27.0.0-alpha.0.0.0 (Alpha), 29 October 2026 — Node.js

1. Node.js releases — Node.js

1. Node.js 26.13.0 (LTS), 28 October 2026 — Node.js

1. CODENAMES.md — Node.js Release Working Group

1. Node.js release index (index.json) — Node.js

1. Lambda Event Function runtimes — AWS

1. Introducing public preview runtimes on AWS Lambda, starting with Node.js 26 and Python 3.15 — AWS Compute Blog

1. Node.js 26 LTS is now Generally Available on Vercel, 29 October 2026 — Vercel

1. Supported languages in Azure Functions, last updated 22 October 2026 — Microsoft Learn

1. Cloud Run functions runtime support schedule, last updated 26 October 2026 — Google Cloud

1. The Digital Personal Data Protection Act, 2023 — Ministry of Electronics and Information Technology, Government of India