Node.js LTS vs Current: Which Version Should You Use?

Use an actively supported Node.js LTS release for production. LTS means Long Term Support: a release phase with a longer maintenance window. Current is the newest stable release line, where new runtime features arrive first. Every major starts as Current; the version number alone does not tell you whether it is LTS or still supported.

As checked on 21 September 2026, Node 24 is Active LTS, Node 22 is Maintenance LTS, and Node 26 is Current. Node 20 and Node 25 have reached end of life. The live version card below shows patch releases; use the dated table for support phases.

Node LTS vs Current at a glance

Current is a stable release, not a beta. Both lines follow Node's versioning policy; experimental APIs can have different stability guarantees. LTS reduces upgrade pressure, but you still need patch updates and application tests.

Which Node.js versions are supported in 2026?

These dates come from the Node.js release schedule, checked on 21 September 2026. Future transitions are scheduled dates, not a guarantee that the calendar cannot change.

For a new production app today, I would start with Node 24 and test its dependencies before deployment. An app on Node 22 can continue receiving maintenance fixes while its upgrade is prepared. Do not interpret “LTS” in an old download filename as proof that the release is still supported.

The release schedule, in plain terms

The old even/odd rule is changing. Through Node 26, Node used a twice-yearly major release cycle: even majors entered LTS after their initial Current period; odd majors such as 23 and 25 did not. That is why older guides say “even for production.”

Node's current release policy says that starting with Node 27, major releases move to an annual cycle and every major is intended to become LTS. The cycle includes an Alpha phase before the stable Current release, then approximately six months as Current before LTS. An odd version number will no longer mean “never LTS.”

For the established Node 22–26 schedule, the roughly three-year lifetime includes the initial Current period plus about 30 months of LTS. For example, Node 22 first shipped in April 2024, entered LTS in October 2024, moved to Maintenance in October 2025, and is scheduled to end support in April 2027. Check the official schedule for the specific line rather than calculating a deadline from parity.

When LTS is the right choice (almost always)

Use supported LTS for production services, scheduled jobs, and development environments that should match production. Active LTS is a useful default for new work; Maintenance LTS remains supported while you test a migration.

For a published library, test the Node versions your package actually claims to support. An engines.node declaration describes compatibility; it does not install Node or prove that your tests pass on every matching release.

When Current is actually worth it

Current is useful for testing an upcoming LTS, evaluating a new API, or working on runtime compatibility. Add it to a separate CI job so you can distinguish a new-runtime failure from a regression on your supported production versions.

Before depending on a feature, check whether it is stable and whether it has already been backported to LTS. If you deploy Current, budget for runtime changes and watch its support schedule.

How to check and install each line

Start with the runtime your shell actually uses:

node --version
node -p "process.execPath"

Compare the reported major with the support table. v26 is Current in September 2026 even though 26 is even. See how to check Node.js versions if your terminal, editor, and deployment disagree.

With nvm, choose one installation route:

# Latest LTS
nvm install --lts
nvm use --lts

# Latest Current, for deliberate testing
nvm install node
nvm use node

With fnm, fnm install --lts installs the LTS release; use fnm list and fnm use VERSION to select the installed version. For Windows installers, package managers, and verification after the change, see how to update Node.js.

Choose one base image in a Dockerfile:

FROM node:24-alpine

A major tag keeps you on that major but still moves as patches and image updates ship. node:lts-alpine can also move to a new major at LTS promotion. Pin a reviewed image digest when you need an immutable image, and update it deliberately to receive fixes. A major tag alone does not make a build reproducible.

Commit the project's chosen version in .nvmrc or .node-version and use the same policy in CI.

What "Active" vs "Maintenance" LTS means for you

Active LTS receives a wider selection of fixes and backports. Maintenance narrows the scope of changes as the line approaches end of life. The important distinction for an existing app is whether its release is still supported, not whether it is the newest major.

When your line enters Maintenance, schedule the next upgrade and run your application tests on the target version. Native addons may need a compatible release or rebuild; Node-API addons have different ABI guarantees. Keep a tested rollback path for the application deployment.

LTS, Current, and CI matrices

This workflow tests the two LTS majors supported on the review date. It assumes a committed package-lock.json and an npm test script:

name: CI
on: [push, pull_request]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        node: ['22', '24']
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

Add Node 26 as a separate compatibility job if you want to test Current. Keep the blocking matrix aligned with your declared support policy. A major range may select a matching runner-cached patch; use check-latest: true to request the newest matching release. For an exact runtime, pin a full version and update that pin regularly. The setup-node guide covers these choices and dependency caching.

FAQ

See also

• Update Node.js on Windows, macOS, and Linux
• Check which Node executable is running
• Pin a Node version per project
• Configure actions/setup-node and dependency caching