Node.js 26 LTS: plan your upgrade
Node.js 26 entered long term support on 28 October. If you run a production application on Node.js 22 or 24, now is a good time to test the next runtime. Intercube can prepare a managed environment and help your team verify that the build, web process and workers all run the release you tested.
- Author
- Intercube
- Published
- Reading time
- 4 min read
01
What changed when Node.js 26 became LTS
The Node.js project announced 26.13.0 on 28 October as the first release in the Lithium LTS line, with updates planned through April 2029. The LTS designation is the change in this release. The project lists no further changes from 26.12.1 apart from release metadata.
Node.js 22 and 24 remain on the published maintenance schedule. A team already on a supported and patched runtime can use the new LTS line to plan a tested upgrade. Check your framework, dependency support and hosting image before choosing a production cutover.
On 3 November, the project announced security updates for the 22, 24 and 26 lines on or shortly after 11 November. Keep the security update for your current line separate from the major upgrade so a compatibility test does not delay patching.
02
Check what actually runs in production
Record the Node.js version used by the build, the running web process and each worker. A package constraint, a CI image and the server that launches your application can specify different versions. For a container deployment, inspect the final runtime image as well as the image that runs the build.
The release notes flag a Linux dependency when moving from an earlier LTS line. Official binaries have linked against libatomic since Node.js 25. Check that the target Linux image supplies it. Rebuild native modules in the target environment so your test includes the same libraries and architecture production will use.
03
Rehearse the release on the target runtime
Install the locked dependencies and build the application in a preview or staging environment. Test startup and shutdown, then run a representative API request and a real background job against test data. Check database connections, environment variables and job retries. A successful build tells you little about a worker that still starts with the old binary.
Record the release artifact and runtime together. If a compatibility issue surfaces at cutover, both may need to be restored. Agree who can make that decision, and verify that scheduled jobs and workers have switched before you retire the previous environment.
04
Give the runtime change an infrastructure owner
Intercube engineers can review your current Linux environment, confirm the production runtime for your application and prepare a target environment for rehearsal. Your team can test the application and dependencies against that environment while our engineers handle the infrastructure and release setup.
Intercube deployment pipelines are included with managed hosting. You can build and deploy through Intercube without setting up a separate GitHub Actions deployment workflow or paying a separate runner bill for that pipeline. If you are moving from a self-managed server, we can plan the application transfer and cutover as part of your included migration.
Before moving to Node.js 26
- Check the release schedule for your current Node.js line.
- Confirm the target build image and production runtime separately.
- Check libatomic on the target Linux image and rebuild native dependencies.
- Rehearse web requests and worker jobs before production.
- Keep the previous release and runtime available for recovery.