Plan for Node.js 26 long-term support

A schedule is not a completed release announcement

On 27 October 2026, the official Node.js release page lists branch 26 as Current, while the official schedule plans its LTS milestone for 28 October. Do not replace those observations with a claim that the transition has already occurred. This article prepares an upgrade decision; review the actual release status and announcement again on the day of use. A planned calendar entry is not itself confirmation that a release was completed.

Changing a runtime involves more than replacing a command on a workstation. A service, container, build tool and scheduled job may use different interpreters. The inventory example records the running process and selected native-dependency version information in a new file. That evidence can support comparisons between environments, but does not prove package compatibility or correct service configuration. Collect it inside the intended process or container rather than assuming that the administrator's shell represents the deployment.

Inventory the running process and native dependencies

The policy is a dated snapshot of the official schedule. Before the planned milestone it reports the Current state. Reaching the date still requires confirmation of the actual announcement and application tests instead of automatically approving an upgrade at midnight. A different major branch or expired policy also requires review. This boundary prevents a simple version-number comparison or local clock transition from being mistaken for a complete operational acceptance decision.

Save the four files together. The tools run on Node.js 22 or newer without an external dependency. Execute node --test test_schedule.mjs to exercise explicit date boundaries; the test does not change the computer's clock. Run node schedule_check.mjs to inspect the current interpreter. A request to review a different branch is expected when the tool is not running under version 26 and does not mean every workstation needs an immediate upgrade.

Run node runtime_inventory.mjs in a test directory to create a fresh evidence file. Exclusive creation preserves previous output, allowing deliberate comparison of the old and target environments. Before deployment, exercise dependency installation, native addons, network connections, Persian text processing and background jobs in isolation. Passing the calendar-policy test is not a substitute for running the application's own suite or measuring resource use under a workload representative of the real service.

{
  "reviewed": "2026-10-27",
  "reviewBy": "2026-11-03",
  "source": "https://raw.githubusercontent.com/nodejs/Release/main/schedule.json",
  "v26": {"start": "2026-05-05", "lts": "2026-10-28", "maintenance": "2027-10-20", "end": "2029-04-30"}
}

import fs from 'node:fs';

export function assess(version, policy, today) {
  if (!/^\d{4}-\d{2}-\d{2}$/.test(today) || today < policy.reviewed || today > policy.reviewBy) return 'review-policy-date';
  if (!/^v?26\.\d+\.\d+$/.test(version)) return 'review-a-different-runtime-branch';
  if (today < policy.v26.lts) return 'current-before-scheduled-lts';
  return 'verify-actual-lts-announcement-and-application-tests';
}

if (process.argv[1] && new URL(import.meta.url).pathname.replace(/^\/(?:([A-Za-z]:))/, '$1').endsWith(process.argv[1].replaceAll('\\', '/'))) {
  const policy = JSON.parse(fs.readFileSync(new URL('./schedule_snapshot.json', import.meta.url), 'utf8'));
  console.log(JSON.stringify({version: process.version, assessment: assess(process.version, policy, new Date().toISOString().slice(0, 10))}));
}

import fs from 'node:fs';
const evidence = {version: process.version, platform: process.platform, architecture: process.arch,
  versions: {modules: process.versions.modules, openssl: process.versions.openssl, v8: process.versions.v8}};
fs.writeFileSync('runtime-inventory.json', JSON.stringify(evidence, null, 2) + '\n', {flag: 'wx'});
console.log('Saved runtime-inventory.json; record this inside the target service/container.');

import {test} from 'node:test';
import assert from 'node:assert/strict';
import fs from 'node:fs';
import {assess} from './schedule_check.mjs';
const policy = JSON.parse(fs.readFileSync(new URL('./schedule_snapshot.json', import.meta.url), 'utf8'));
test('scheduled LTS date is not treated as a completed announcement', () => {
  assert.equal(assess('v26.12.1', policy, '2026-10-27'), 'current-before-scheduled-lts');
  assert.equal(assess('v26.12.1', policy, '2026-10-28'), 'verify-actual-lts-announcement-and-application-tests');
  assert.equal(assess('v26.12.1', policy, '2026-11-04'), 'review-policy-date');
  assert.equal(assess('v24.22.1', policy, '2026-10-27'), 'review-a-different-runtime-branch');
});

Exercise an expiring policy and application tests

For a controlled release, record the exact runtime version and how its package or container image is built, then define rollback criteria. Revisit the official source when the LTS status is announced and retain the refreshed policy with compatibility evidence. Do not reuse an expired assessment as permanent approval. The objective is a reviewable, recoverable change based on real application behavior, rather than an automatic move to every newly numbered runtime that appears.

Editorial guidance: Liyan Knowledge.

Published: 27 October 2026