deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Node.js 26 'Lithium' reaches LTS, putting Lambda upgrades on an April 2027 clock

Node.js 26 became the long-term support line on October 28, 2026, with its Lambda runtime in preview ahead of a November GA. Teams still on nodejs22.x face an April 2027 deprecation deadline.

Node.js 26 'Lithium' reaches LTS, putting Lambda upgrades on an April 2027 clock

Node.js 26, codenamed "Lithium", became the project's active long-term support release on October 28, 2026, opening an upgrade window that serverless teams in particular should treat as a planning exercise rather than a last-minute scramble. According to a dev.to article walking through the release, the LTS designation arrived with version 26.13.0 — a formality that flips metadata such as process.release to LTS and adds nothing beyond 26.12.1 — and the line will keep receiving fixes until the end of April 2029.

The support timeline, including on Lambda

On AWS Lambda, the nodejs26.x runtime is currently in public preview, with AWS documentation pointing to general availability in November 2026, the article reports. That gap is useful: functions can be tested against the new runtime before anything in production moves.

The runtimes already in place matter just as much. As laid out in the dev.to post, nodejs22.x ("Jod") is set for deprecation on April 30, 2027, with updates blocked from August 31, 2027, while nodejs24.x ("Krypton") is scheduled for deprecation on April 30, 2028.

The Node.js project is also changing its release rhythm, the article notes. Historically only even-numbered releases graduated to LTS, with odd-numbered ones retiring after six months — Node.js 25 hit end of life at the close of March 2026. From Node.js 27 onward, the project ships one major version per year, and each becomes LTS after a six-month Current phase.

What arrives with Node 26

Because Node.js 25 never went LTS, teams moving up from 24 pick up two releases' worth of changes. The headline addition for everyday code is the Temporal API, enabled by default with no flag required. Temporal addresses the long-standing weaknesses of Date — zero-based months, mutable instances, no real time-zone arithmetic — with distinct types such as Temporal.Instant for exact points in time, Temporal.ZonedDateTime for a moment tied to a specific zone, and Temporal.PlainDate for a plain calendar date. The article demonstrates the payoff with a rental-due-date example: adding two days across a daylight-saving transition preserves the wall-clock time, where naive Date arithmetic lands an hour off.

The bundled V8, version 14.6, contributes Map.prototype.getOrInsert() and getOrInsertComputed() for the read-or-create pattern, plus Iterator.concat() for chaining iterators without building intermediate arrays. Carried over from Node.js 25 are Uint8Array.fromBase64() and toBase64() (with hex equivalents) and a noticeably faster JSON.stringify — relevant to Lambda functions that assemble JSON responses or encode binary payloads for API Gateway. The HTTP stack moves to Undici 8, the Web Storage API stays on by default but localStorage returns undefined in Node 26 unless a storage file is configured, and the permission model's --allow-net flag, also dating from Node 25, is more useful for local tooling and CI than on Lambda, where IAM and VPC already handle isolation, the author points out.

One caveat from the author's own testing: with the esnext library setting, TypeScript 7.0.2 already understands Temporal, getOrInsert and fromBase64, but still reports an error for Iterator.concat.

What can break

Most projects keep running after the upgrade, but the article lists changes worth checking deliberately before flipping the runtime:

  • The internal _stream_readable and _stream_writable modules, and their siblings, have been removed; some older libraries still import them directly.
  • http.Server.prototype.writeHeader() is gone in favor of writeHead().
  • fs.F_OK, fs.R_OK, fs.W_OK and fs.X_OK are no longer top-level exports; the constants live under fs.constants.
  • SlowBuffer and assert.CallTracker reached end of life in Node 25.
  • Corepack is no longer bundled, so CI pipelines that enable pnpm or Yarn through it need a separate install.
  • module.register() now emits a runtime deprecation warning, and --experimental-transform-types was removed.
  • Native addons need a rebuild because NODE_MODULE_VERSION moves to 147.
  • Official Linux binaries link against libatomic, a package slim container images may be missing.

Teams jumping straight from nodejs22.x also inherit the Lambda-specific changes AWS introduced with nodejs24.x: callback-style handlers are no longer supported, context.callbackWaitsForEmptyEventLoop is gone, and context.succeed, context.fail and context.done have all been removed.

Why it matters

For many serverless teams, the binding deadline is not Node 26's LTS date but the April 2027 deprecation of nodejs22.x — roughly six months out, as the dev.to article frames it. Starting now means the upgrade fits into normal sprint work instead of arriving alongside AWS's deprecation emails. The preview runtime offers a low-risk way to probe behavior early, but the article's sharpest warning deserves repeating: what works under Node 26 on a laptop is not guaranteed to behave identically in the Lambda runtime, so verify features there directly. Combined with the shift to a predictable one-LTS-per-year cadence, runtime upgrades become a recurring, schedulable task rather than a surprise.

  • #node-js
  • #aws-lambda
  • #javascript
  • #serverless
  • #temporal-api

Related posts