As of September 30, 2026, the Node.js project lists Node.js 24 and Node.js 22 as LTS release lines, Node.js 26 as Current, and Node.js 20 as end-of-life. Production applications should use an Active LTS or Maintenance LTS release unless the organization has a deliberate, tested reason to do otherwise.
The exact release matrix changes over time. Use the Node.js project’s current release page as the source of truth before setting a production standard or migration deadline.
The Node.js release page currently lists the 24.x line, codename Krypton, as LTS. For many teams planning a 2026 production migration, this is the natural newer LTS target when application, dependency, platform, and vendor compatibility are established.
The 22.x line remains LTS and continues to be a supported production option. Existing stable workloads do not need to move solely because a newer major exists; migration timing should consider remaining support runway, dependency support, platform commitments, and engineering risk.
Node.js 26 was released in May 2026 and is currently the Current line. The Node.js project’s published schedule places its LTS transition in October 2026. Use Current for compatibility testing and early validation unless your production policy explicitly accepts Current releases.
The Node.js project now lists Node.js 20 as end-of-life, alongside older release lines. EOL means the project no longer maintains that line, including security fixes. Treat remaining production use as lifecycle debt that needs an owner, migration plan, and explicit risk handling.
Starting with Node.js 27, the project has announced a revised annual release model in which each major version is planned to progress to LTS. That roadmap is useful for long-range platform planning, but the live release schedule remains authoritative because planned dates can change.
The Node.js project identifies several consequences of running an EOL line: no further vulnerability fixes, increasing tool-chain breakage, ecosystem drift as packages stop supporting the old runtime, and potential compliance concerns around unmaintained software. Those effects compound over time.
A service can appear healthy while its support position deteriorates. The application may still start, tests may still pass, and containers may still deploy, but the team loses a reliable upstream path when a runtime vulnerability, OpenSSL change, operating-system update, native module problem, or package compatibility issue appears.
Do not reduce lifecycle risk to the version printed by node --version on a web server. Node.js can exist in application containers, serverless functions, CI runners, JavaScript-based build actions, developer images, test infrastructure, static-site pipelines, desktop tooling, package scripts, internal CLIs, and third-party products. An upgrade program is incomplete until those locations are understood.
The Node.js project explicitly recommends Active LTS or Maintenance LTS for production applications. Select the supported LTS line that gives adequate runway without forcing unnecessary simultaneous changes across frameworks, native dependencies, cloud platforms, and observability tooling.
Run representative CI and staging workloads on the Current line to expose future incompatibilities early. That lets teams fix deprecations, package constraints, native-addon problems, and runtime assumptions before the next LTS adoption becomes urgent.
If a workload cannot leave an EOL line immediately, record why, who owns the risk, which compensating controls apply, what dependencies block the migration, and the date when the exception expires. “Legacy” is a description, not a control.
Build the migration from evidence rather than repository names or CMDB assumptions.
package.json engine constraints and package-manager metadata.Reconcile multiple sources: repository search, container registries, cloud inventories, process telemetry, endpoint/software inventories, CI configuration, SBOMs, and deployment manifests. Differences between sources are useful findings. They reveal unmanaged or poorly owned runtime use.
Install from a clean lockfile under the target Node line. Review engine constraints, deprecated packages, native addons, post-install scripts, package-manager behavior, and binary availability. A dependency that “works on my machine” can still fail in a minimal container or managed build environment.
Run unit, integration, API-contract, end-to-end, and error-path tests. Pay extra attention to networking, TLS, crypto, streams, URL handling, timers, workers, child processes, file-system behavior, serialization, and anything that depended on a previously deprecated API or undocumented behavior.
Compare throughput, latency percentiles, CPU, memory, garbage collection, startup time, and connection behavior under production-like load. A successful functional test does not prove the new runtime fits existing resource limits or autoscaling assumptions.
Verify CI runners, scanners, test reporters, APM agents, OpenTelemetry instrumentation, source maps, debugging, crash capture, deployment tooling, health checks, and rollback automation. Runtime upgrades often expose assumptions in the tooling around the application rather than the application itself.
Promote the runtime change through representative lower environments, then use a canary, blue/green, phased fleet, or similar controlled production rollout. Define success and rollback thresholds before the first production change: error rate, latency, crash frequency, memory growth, queue depth, connection failures, authentication errors, or business-transaction failures may all be relevant.
Keep the runtime change isolated from unrelated framework rewrites when practical. Combining a Node major upgrade, package-manager replacement, application-framework major version, base-image change, and infrastructure migration in one release makes root-cause analysis and rollback much harder.
After deployment, rerun inventory and SBOM discovery so the migration is closed by evidence rather than by the last planned ticket. Search for old base images, dormant functions, standby instances, test environments, and forgotten CI definitions. EOL runtime debt frequently survives in non-primary paths.
Maintain an approved-version policy tied to the Node.js release schedule. Specify production LTS expectations, how soon newly EOL lines must leave service, how exceptions are approved, and which team owns schedule monitoring.
Test against the current production line and at least one future target. Fail or warn on unsupported engine declarations, deprecated base images, and disallowed runtime versions. Make the supported version visible in reusable build templates rather than copied across hundreds of repositories.
Measure how long it takes from target selection to validated production rollout, how many services miss policy deadlines, which dependency categories block upgrades, and how many runtime exceptions recur. Those measures identify structural platform debt better than a one-time migration percentage.
Ask suppliers which Node lines their products or runtimes use, how quickly they adopt security releases, and how customers learn about support changes. A managed service can hide runtime lifecycle risk rather than eliminate it.
Days 1–30: inventory runtime use, classify support state, select target LTS lines, and establish owners. Days 31–60: update dependencies and CI matrices, validate native modules, performance, observability, cloud/platform support, and rollback. Days 61–90: roll out by risk tier, verify removal of EOL instances, close or time-bound exceptions, and turn the release schedule into a recurring platform control.
No. The Node.js project currently lists Node.js 20 (Iron) as end-of-life. Remaining production use should be treated as unsupported runtime debt and migrated or explicitly risk-managed.
Use a currently supported LTS line that is compatible with the application and target platform. As of September 2026, Node.js 24 and Node.js 22 are listed as LTS. Recheck the live Node.js release matrix before standardizing.
Node.js 26 is currently the Current release and is scheduled to enter LTS in October 2026. The project recommends LTS for production, so many teams will evaluate 26 now and adopt it after their own compatibility criteria and the project’s actual LTS transition are satisfied.
No. EOL means the release line is no longer maintained by the Node.js project. That creates increasing security and compatibility risk, but compromise is a separate factual question that requires evidence.
Release status and planned dates change. This page was reviewed September 30, 2026; verify the current Node.js release schedule before setting production targets or lifecycle deadlines.
Use the secure delivery and supply-chain guides to make runtime upgrades repeatable across repositories, CI, artifacts, and production environments.
Follow the next implementation topic without returning to search.
Build verifiable software supply-chain controls
Continue readingIntegrate compliance evidence into CI workflows
Continue readingDesign and operate APIs with current security controls
Continue readingUse the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.