Job node-runtime-to-24-lts-upgrade · revised 11 October 2026

Move one Node.js 18, 20 or 22 app to Node 24 LTS with builds and tests passing

Run one Node.js app on Node 24 LTS: clean install from the lockfile, native modules rebuilt or replaced, the test suite and the container or CI configuration all on 24, checked on a copy.

You might be seeing

The Node.js releases page shows your version as end of life
A package install warns that a dependency needs a newer Node.js engine
A native module fails to build or load after the base image changes

Enquire — from £695 Check if it fits first What to send us

No passwords, keys, card details or admin invites needed to start.

From £695

Final price agreed before we start

From £695 for one app with one lockfile, up to three native modules that have Node 24 releases, a runnable test command and up to five named flows. We inspect the lockfile and run the install on Node 24 before a final fixed quote. A module without a Node 24 release, many native modules or a pinned host runtime lead to a separate decision or a stop.

You pay: After the agreed checks pass and you sign off. No advance payment.
Includes: One Node.js app moved to Node 24 LTS on a copy; Native modules rebuilt, upgraded or replaced; Engine range, container, CI and host settings aligned, with a release plan and way back
Technology: Node.js, npm, Node.js 18, 20 or 22 to Node.js 24 LTS
Delivery: Start window and delivery date agreed in writing after eligibility and access checks.

Dates that matter

30 Apr 2026
Node.js 20 reached end of life on this date, according to the Node.js release schedule.
30 Apr 2027
Node.js 22 is scheduled to reach end of life on this date. The project says dates are subject to change.
30 Apr 2028
Node.js 24 is scheduled to reach end of life on this date, with maintenance LTS starting 20 October 2026.

Source: github.com/nodejs/release

This is a new fixed-price service. We agree scope and checks with you before starting, and you pay after it works and you sign off.

Enquiry only: no checkout, charge or booking. The written quote confirms the total price and any applicable tax before you accept.

What usually happened

The app runs on a Node.js release the project has stopped supporting, or will within months. Moving the runtime is not just changing a version number: native add-ons that use V8 or the Node C++ interfaces have to be rebuilt or replaced for each major release, dependencies pin engine ranges, and the container image, CI job and host setting each hold their own copy of the version. A start that succeeds on a developer laptop can still fail in the build image or in a scheduled job.

Who it’s for: A founder or engineering lead whose Node.js service or build still runs on a release the Node.js project no longer supports, or soon will not.

Usually starts when: A host or function platform announces that an older Node.js runtime is being retired, a dependency now requires a newer Node.js, or the team's base image is on an end-of-life release.

The result: The app installs cleanly from its lockfile on Node 24 LTS, every native module loads on it, the test suite passes as it did on the old version, and the version is set the same way in the engine range, container base image, CI and host configuration, with your site holder holding a release plan and a way back.

Check whether this job fits

Five short questions. Your answers stay on this page unless you choose to email them.

Which Node.js version does the app run on in production?

18, 20 or 22 16 or older 24 or newer Not sure

Does the app use native or compiled packages?

Examples include image processing, password hashing, database drivers with a compile step or anything that runs node-gyp on install.

No, or I do not think so Yes, a few Not sure

Is there a test command that runs without production data?

Yes No tests

Where is the Node.js version set?

In one or two places In many places, including scheduled jobs and functions

Who can change the runtime in production?

Our developer or host Nobody yet

Answer the questions to see whether this job fits.

Nothing is sent anywhere until you choose to email us.

Send an enquiry about this outcome

How to read your answers: any answer below means this fixed job needs a closer look or doesn’t fit.

Which Node.js version does the app run on in production? 16 or older: Older apps often need dependency upgrades first. Send the version and the lockfile name; the inventory and plan may be the right start. Upgrade inventory and plan
Which Node.js version does the app run on in production? 24 or newer: Nothing to move for this job. If you want the version kept supported, ask about the monthly service. Keep versions supported
Which Node.js version does the app run on in production? Not sure: Check the host's settings page, the Dockerfile base image and any .nvmrc or engines entry; they may disagree, so send all three.
Does the app use native or compiled packages? Yes, a few: Each one is checked for Node 24 support. A module with no release for Node 24 is a stop condition for this fixed job.
Does the app use native or compiled packages? Not sure: Ask the developer to look for binding.gyp files or .node files in the installed packages.
Is there a test command that runs without production data? No tests: We rely on the named flows checked on staging and written up. Tell us the flows.
Where is the Node.js version set? In many places, including scheduled jobs and functions: Each place is changed and checked. List them in your enquiry so the scope names them all.
Who can change the runtime in production? Nobody yet: You keep the account. Agree who changes the runtime and who can go back before we start.

Checks you can run yourself

Read the version the machine runs
Ask whoever works on the app to run this in a copy of the project folder and compare it with the host's settings page.
```
node --version
```
Look for: The major number. Send both the local and the host's value if they differ.
Look for native modules
Run this read-only search in a copy of the project folder after dependencies are installed.
```
find node_modules -name binding.gyp -o -name "*.node" | head -20
```
Look for: Any file names. Send the package folder names they sit in, not file contents.

What you get

The changed lockfile, package manifest and build configuration as a pull request
A list of every native module and how each was handled
The test, build and start logs from the old and new versions, and the warnings found
A release plan with the order of changes and the steps to go back

Included

One Node.js application or service with one lockfile and a runnable test command
A clean install on Node 24, with each native module rebuilt, upgraded to a release that supports Node 24, or replaced with your agreement
Recording every deprecation or runtime warning the app prints on Node 24 and fixing those that change behaviour
Setting the Node.js version in the package engines field, the container base image or version file, the CI configuration and your host's settings, as applicable, so they all agree
A staging run of the agreed start command, background workers and up to five named business flows

Not included

Major upgrades of frameworks, such as Express 4 to 5, which are separate jobs
Converting the codebase to ES modules, TypeScript or a new bundler
Changing the host, database or operating system
Production deployment, which stays with your site holder
Fixing or replacing a native module that has no release for Node 24 and no maintained alternative

How we know it’s done

Agreed with you before work starts. Each check produces evidence you keep.

On Node 24 a clean install from the lockfile finishes with no engine warning, and the build and the test command finish with the same tests passing as the recorded baseline
Evidence: Install, build and test logs from the baseline and the final state
Every native module found in the installed packages loads on Node 24, and each is recorded as rebuilt, upgraded or replaced
Evidence: The native-module list with one load result per module
The Node.js version in the engine range, version file, container base image, CI configuration and host settings is the same Node 24 line everywhere it is set
Evidence: A table of each place, the old value and the new value, checked by the reviewer
The start command and any background workers run on staging for the agreed period with no new error, and each of up to five named flows completes
Evidence: Start logs and screenshots or redacted records for each flow

Sign-off. You review the logs, the native-module list and the places the version was changed before your site holder changes the runtime in production. Passing tests on staging do not prove production traffic patterns.

If it fails. If the agreed acceptance checks do not pass, you do not pay and you keep our findings and the way-back steps.

When it fits, and when we stop

It fits when

The app runs on Node.js 18, 20 or 22 today and has a lockfile
The test suite or a documented set of checks can run on a copy without production data or secrets
You can name up to five business flows and how to exercise them on staging
A person on your side can review the change and an authorised site holder can change the runtime in production

We stop and tell you if

A required native module has no release that builds on Node 24 and no maintained alternative
The app depends on a private package or a vendor binary we cannot obtain for Node 24
The app can only be run with live secrets or production data
The runtime is pinned by the host or platform and the host cannot offer Node 24

What could go wrong

Keep the previous container image or host runtime setting and the previous lockfile available. The way back is to restore the old setting and image. If the app wrote cached or serialised values in a new format after release, the plan says how to check them before reverting.

Scroll the table sideways to read it all.

Risk	How we handle it
A native module builds on a developer machine but not in the container image	The install and build are run in the same kind of image your host uses, and the base image is part of the change.
A deprecation warning on 24 hides a behaviour change that tests do not exercise	Every warning is recorded and either fixed or listed with the reason it is safe, and the staging flows exercise the affected paths.
The version is changed in one place but not in a scheduled job or function	We list every place the version is set before changing any, and check each one afterwards.

A second reviewer checks the native-module decisions, every dependency change and the places the version is set, and re-runs the start command from the handover notes alone.

How we deliver

We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.

Restore a copy in an isolated workspace on the current Node.js version, run the build, tests and start command and record the baseline
Install from the lockfile on Node 24 and list every native module, checking each for a release that supports it
Rebuild, upgrade or replace each native module with the smallest change and re-run the install, build and tests
Record every runtime warning on Node 24 and fix those that change behaviour
Align the engine range, container base image, version file, CI configuration and host settings and run the staging flows
Independent review of the dependency changes and the environment settings, then hand over the pull request, the logs and the release and way-back steps

This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.

Need to keep it working?

Discuss a monthly service that keeps the runtime and dependencies on supported versions.

Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.

Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.

What you can check

This is a new service. We have not delivered this job for a client yet.

Other ways to get this done

If your host can only offer a different supported LTS line, that is a valid target; the Node.js releases page says production applications should use Active LTS or Maintenance LTS releases. We scope the target with you. nodejs.org
The Node.js project says commercial support for end-of-life lines is available through OpenJS Ecosystem Sustainability Program partners. That buys time but does not move the app to a supported release. nodejs.org

Questions

Why 24 and not the newest release?

Node.js 24 is an LTS line, and the Node.js project says production applications should use Active LTS or Maintenance LTS releases. The schedule lists Node.js 26 reaching LTS on 28 October 2026; a different target is a different scope.

Will you upgrade Express or my other frameworks too?

No. Major upgrades of frameworks are separate jobs, because their changes and tests differ. Express 4 to 5 is offered separately.

What if a native module cannot be made to work on 24?

We say so with the evidence and either agree a replacement with you or stop. You do not pay for a result that does not pass its checks.

Send an enquiry

Send us

The Node.js version and the package manager and version the app uses
Where the version is set: engine range, version file, Dockerfile, CI, host settings
Any native or compiled packages you know about
The business flows that matter most

Later, once you agree

A controlled copy of the source and lockfile with secrets removed, through the agreed company-controlled secure handoff
The Dockerfile, CI configuration and host settings page values, with secrets removed
Instructions to run the tests and the start command, plus synthetic fixtures if needed
A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.

You own the code, build pipeline, hosting and secrets. We work from an authorised copy with secrets removed, and your site holder changes the runtime in production under your accounts. We never ask for passwords or tokens in the first enquiry.

Email fallback: open your mail app

If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “node-runtime-to-24-lts-upgrade” as the subject.