Which Node.js line should you move to? Read the project's schedule, then ask your host

Two clocks, and the earlier one wins

The Node.js project publishes a release schedule that says when each line enters long-term support, moves to maintenance and reaches end of life. Your host publishes its own list of runtimes, and may stop offering a line before the project stops supporting it. The date that matters to you is the earlier of the two. Ask the host for its date in writing and record the day you looked at each page.

• Project schedule: when the line stops getting fixes.
• Host runtime list: when you can no longer select it.
• Your own deadline: customer or security questionnaires that name a version.

Reading the schedule

As checked on 11 October 2026, the project's releases page lists 26 as Current, 24 and 22 as LTS, and 25, 20 and 18 as end of life. It says production applications should only use Active LTS or Maintenance LTS releases. The schedule rows below are copied from the project's table and are subject to change; the project says so itself.

• A line in Current is not a production target, whatever its number.
• The project says LTS typically guarantees critical bug fixes for a total of 30 months; that is a statement about upstream fixes, not about your host's runtime list or your dependencies' own support.
• Commercial support for lines past end of life exists through the OpenJS partners the project names, but it keeps an unsupported line running; it does not move your app to a supported one.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

line | release    | LTS start  | maintenance | end of life
20.x | 2023-04-18 | 2023-10-24 | 2024-10-22  | 2026-04-30
22.x | 2024-04-24 | 2024-10-29 | 2025-10-21  | 2027-04-30
24.x | 2025-05-06 | 2025-10-28 | 2026-10-20  | 2028-04-30
26.x | 2026-05-05 | 2026-10-28 | 2027-10-20  | 2029-04-30

Find every place the version is set

A Node.js version is rarely set in one place. Look for the engines entry in package.json, a version file such as .nvmrc, the base image in each Dockerfile, the CI configuration, the host's runtime setting, and any scheduled job or serverless function with its own runtime. The npm documentation says the engines field is advisory only unless engine-strict is turned on, so a warning there does not stop a wrong version from running.

• List every place before changing any of them.
• Change them together and check each one afterwards.
• A build that passes on a laptop proves nothing about the host's image.

What choosing a line does not decide

A runtime line decision is separate from a framework major version, which has its own migration guide, and from compiled modules, which have their own support. Express 5, for example, needs Node.js 18 or newer, so a service below 18 has to move the runtime first. Record the decision and its reasons, so the next review starts from them.

• Do not combine a runtime move with a framework major in one change.
• Check native modules before you commit to a date.

How the paid job is accepted, and what to send

The fixed Node.js 24 LTS job is accepted when a clean install from the lockfile finishes without an engine warning, build and tests match the baseline, every native module loads, and the version is the same in each place it is set, with the start command running on staging. Send the production version, where it is set and any compiled packages. Prices are untested proposals and payment follows the agreed checks.