Node.js Release & LTS Policy

Node.js ships on a predictable cadence - production services should run Active or Maintenance LTS releases, never short-lived Current odd majors.

Recipe

Quick-reference recipe card - copy-paste ready.

When to reach for this:

• Choosing a base image for a new microservice
• Writing an ADR for an LTS upgrade
• Auditing whether any fleet still runs End-of-Life Node
• Explaining to security why Current releases are blocked in prod

Working Example

// src/health.ts - expose LTS awareness in health checks
import { readFileSync } from 'node:fs';
 
const pkg = JSON.parse(readFileSync('package.json', 'utf8')) as {
  engines?: { node?: string };
};
 
export function healthPayload() {
  const major = Number(process.versions.node.split('.')[0]);
  const allowedMajors = [22, 24]; // Maintenance + Active LTS
 
  return {
    status: allowedMajors.includes(major) ? 'ok' : 'degraded',
    node: process.version,
    enginesPolicy: pkg.engines?.node ?? 'not set',
    ltsPolicy: major === 24 ? 'active-lts' : major === 22 ? 'maintenance-lts' : 'unsupported',
  };
}

// package.json
{
  "engines": {
    "node": ">=24.18.0 <25 || >=22.23.1 <23"
  }
}

What this demonstrates:

• Health endpoints can flag non-LTS runtimes before security scanners do
• engines can express an intentional migration window (22 and 24 concurrently)
• Major version is derived from process.versions.node, not process.version string parsing alone

Deep Dive

How It Works

• New majors release every April and October (roughly). Even numbers (22, 24, 26) enter LTS; odd numbers (23, 25) do not.
• Active LTS receives features, bug fixes, and security patches for ~18 months after promotion.
• Maintenance LTS receives critical fixes only for ~12 more months, then End-of-Life.
• Current (odd majors) is for early adopters and library authors testing compatibility.

Lifecycle Timeline (simplified)

TypeScript Notes

// CI matrix during LTS migration - test both supported lines
const SUPPORTED_NODE_MAJORS = [22, 24] as const;
type SupportedMajor = (typeof SUPPORTED_NODE_MAJORS)[number];
 
function assertSupportedMajor(): SupportedMajor {
  const major = Number(process.versions.node.split('.')[0]) as SupportedMajor;
  if (!SUPPORTED_NODE_MAJORS.includes(major)) {
    throw new Error(`Unsupported Node major: ${major}`);
  }
  return major;
}

Gotchas

• Deploying node:latest or node:current - you may land on an odd major without security SLAs. Fix: pin node:24.18.0-bookworm-slim.
• Staying on Maintenance LTS past EOL - Node 20 EOL means no CVE patches. Fix: calendar reminders 6 months before EOL.
• Skipping LTS versions (20 → 24 with no testing on 22) - breaking changes accumulate. Fix: upgrade to Active LTS at least one cycle before your current line EOLs.
• Treating semver-minor as risk-free - LTS minors can deprecate APIs. Fix: run CI on every LTS patch release.
• Ignoring npm compatibility - each Node LTS bundles a specific npm major. Fix: use bundled npm or document Corepack pins.

Alternatives

FAQs

Related

• Installing & Version Management - fnm, nvm, and engines pinning
• Node.js vs Bun vs Deno - runtime ADR context
• Node.js Fundamentals Best Practices - LTS enforcement checklist
• Before/After Node 20-24 LTS Upgrade - migration case study

Stack versions: This page was written for Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5, and NestJS 11.