Node.js upgrades: the runtime line, the framework major and native modules are different jobs

Three changes that look like one

A Node.js service can be behind in three independent ways. The runtime may be on a line the Node.js project no longer supports. The web framework may be a major version behind. A compiled module may be tied to a particular runtime release. Each has different evidence of success, so changing them together makes a failing build hard to explain.

• Runtime line: set by the Node.js release schedule and by your host.
• Framework major: set by the framework's own migration guide.
• Native modules: set by each module's published support for the new runtime.

What the project publishes

As checked on 11 October 2026, the Node.js releases page lists 26 as Current, 24 and 22 as LTS, and 25, 20 and 18 as end of life. The schedule gives 20 an end of life of 30 April 2026, 22 of 30 April 2027 and 24 of 30 April 2028, with 24 entering maintenance LTS on 20 October 2026 and 26 entering LTS on 28 October 2026. The project says dates are subject to change and that production applications should use Active LTS or Maintenance LTS releases. Your host may retire a runtime before the project does, so ask it for its own date.

• Pick a target from the LTS lines, not from the newest number.
• Treat 'works on my laptop' as the start of the check, not the end: the version is also set in container images, CI and host settings.

Where each problem is solved

Moving a service to a supported LTS line is the fixed Node.js runtime job: a clean install from the lockfile, native modules checked and the version aligned everywhere it is set. Express 4 to 5 is a separate job because its changes are to your route patterns and error handling, not to the runtime. Express 5 itself needs Node.js 18 or newer, so a runtime below that goes first. An app that is behind in many places is better served by an inventory and a ranked plan before any version is chosen.

• Keep a record of which commit changed which layer.
• Do not enable a new runtime in production before the staged checks pass.

What to send first

Send the Node.js version in production and where it is set, the framework and its major version, and the names of any compiled packages. Do not send environment files, tokens or customer data. Fixed prices are untested proposals, and payment follows the agreed checks and your sign-off.