Node.js 26 LTS vs 24: Upgrade Guide for VPS and Bots

The arrival of a new Node.js LTS release affects APIs, Discord bots, Telegram workers, dashboards and many self-hosted applications. It also creates a familiar question: should you move immediately, or stay with the runtime that already works?

The answer depends on your software and deployment. Node 26 offers a longer support horizon, while a patched Node 24 installation remains a valid place to run a compatible application. This guide explains the release change and gives you a practical way to evaluate the upgrade.

What happened on 28 October?

The official Node.js 26.13.0 announcement promoted the 26.x line to Long Term Support under the name Lithium, with updates scheduled through April 2029. The promotion updates LTS metadata from 26.12.1. The major-version features arrived earlier in the Node 26 release cycle.

That distinction matters when assessing claims about speed or compatibility. LTS status establishes the release's support position. Your application still needs tests against its packages, runtime behaviour and deployment environment.

There is also an immediate patching consideration. The 21 October security release addressed issues across Node 26, 24 and 22, including a Brotli decoder vulnerability. Keep your supported line patched while assessing a major upgrade. Moving to a different major version and applying security updates are separate maintenance decisions.

Node.js 26 vs 24: which should you run?

The dates come from the Node.js release schedule. Node 22 is scheduled to remain supported until 30 April 2027; Node 20 reached upstream end of life on 30 April 2026. If you are still on Node 20, our end-of-life migration guide covers the inventory and recovery work involved in leaving that line.

For packaged self-hosted software, follow the maintainer's compatibility matrix and official image. Updating the runtime inside a vendor image without its support can create an installation the vendor has never tested.

Which Node 26 changes deserve testing?

The Node 26.0.0 release notes explain the major-version changes and removals. These are useful review areas, not a claim that every application will break or become faster.

For native modules, some use the stable Node-API interface; others depend more directly on runtime internals. The Node.js ABI explanation describes that difference. Test your exact dependency versions, OS and architecture instead of assuming another project's successful upgrade proves compatibility.

1. Test Node 26 in a staging copy

Record the current application commit, runtime version, lockfile, startup command and data locations. Create a staging checkout or separate VM using test credentials. A bot test instance should use its own bot account or token so that it cannot consume production events or run live scheduled jobs.

First identify the runtime in the environment you intend to change:

node --version
npm --version
node -p "JSON.stringify({node:process.version,lts:process.release.lts,execPath:process.execPath})"

The executable path is useful because a login shell, system service and container may each use a different Node binary. Once deployed, log the version and executable path from the application itself as well.

If you already use nvm on Linux, run it as the application user in the staging environment:

nvm install 26.13.0
nvm use 26.13.0
node --version
npm --version

Use the official nvm installation instructions if it is not installed. Keep the previous runtime available for rollback. The example pins the release checked for this article; review newer patches before using it later.

In the staging project directory, install the committed dependency tree and list the project's scripts:

npm ci --include=dev
npm run

npm ci requires a compatible lockfile and removes an existing node_modules directory. That is why this step belongs in the staging checkout. Including development dependencies makes build and test tooling available even if the environment normally omits them. See the npm ci reference.

Run the scripts that your project actually defines. For an application with test and build scripts, that means:

npm test
npm run build

Then run the resulting application using its real startup method and test useful work. A clean install proves less than a successful database operation, API request, reconnect or scheduled task.

Check the package.json engines requirement in your application and dependencies. Updating that field records an intended compatibility range; it does not make incompatible code work. Update the project's runtime configuration, CI jobs and deployment settings together after testing.

2. Rebuild Docker applications with the target runtime

For a containerised application, change the Node image used by the application build. Installing Node 26 on the Docker host does not replace the binary inside an existing image.

In an existing Dockerfile that already uses the Debian Bookworm slim flavour, the target base can be:

FROM node:26.13.0-bookworm-slim

This is a replacement base line, not a complete application Dockerfile. Keep the existing dependency installation, build stages and startup configuration, and review every stage that executes Node. If your current image uses another distribution, assess that OS change separately.

Build a distinct candidate image from the staging application directory, then inspect its runtime without starting the bot:

docker build --pull -t my-bot:node26-candidate .
docker run --rm --entrypoint node my-bot:node26-candidate -p "JSON.stringify({node:process.version,lts:process.release.lts})"

Exclude host node_modules, secrets and irrelevant files from the build context. Install dependencies inside the target image. Slim images may lack a compiler or system library needed by a native dependency; use the project's supported build process where compilation is required. The official Node Docker image documentation explains its variants.

Test the candidate with staging configuration and data before changing the deployed image. Preserve a separately tagged working image and the corresponding application version. Our container update guide covers recreation, verification and recovery.

3. Check bot dependencies and the hosting runtime

The current discord.js documentation lists Node.js 24.17.0 or newer as its requirement. Node 26 meets that floor, but the requirements for the release you have installed and its optional voice or native dependencies still matter.

For a Discord bot, check login, slash commands, permissions, reconnects and any voice features you use. For a Telegram bot, check long polling or webhook delivery, outbound HTTPS and restart behaviour. Verify persistence and scheduled tasks with test data.

On HYEHOST Bot Hosting, check the supported runtimes offered for your service and confirm the startup version in its console. Plan around an available, tested runtime. If you need direct control over an exact Node installation or container image, a Cloud VPS lets you manage that environment yourself.

HYEHOST offers bot hosting in Wolverhampton, Ashburn and Auckland. Choose a region for your application and its users, while checking its dependencies and external API reachability. For the broader deployment process, see our 24/7 bot hosting guide.

4. Switch the deployed process and verify it

A successful nvm use changes the current shell. A systemd service can still use an absolute path to the old binary. Inspect its startup configuration and update the executable path through your normal deployment process. Reload the service definition if changed, then restart deliberately.

For Docker, deploy the tested candidate image and recreate the service. For a managed bot runtime, apply the supported runtime selection and restart through the panel. In each case, verify the runtime from the new application process rather than relying only on your terminal.

1. Confirm the running Node version and application release.
2. Perform a real command, API call or job, including a persistence check.
3. Watch errors, memory use, latency and reconnect behaviour against the old deployment.
4. Retain the old runtime or image, application build and recovery data until the new deployment is established.

If you changed database schemas or stored formats, switching the runtime back may not be enough. Establish that recovery path before cutover. Keep a protected off-server backup; our VPS backup guide explains what a usable recovery copy needs.

Common Node 26 upgrade problems

For application failures, begin with the first useful error and the last deployment change. If the process is killed for memory pressure, use our OOM diagnosis guide. A runtime upgrade does not remove the need to size the workload.

Keep room for the upgrade process

Staging, dependency installation and container builds can consume more CPU, memory and temporary disk than an idle bot. A separate test VM helps avoid that work competing with production. Choose capacity for the application and its maintenance tasks, then measure actual use.

HYEHOST Cloud VPS provides root access in Wolverhampton, Ashburn and Auckland for your own runtime and Docker deployments. Bot Hosting is a simpler option for supported bot runtimes, while Storage Box can hold encrypted off-server recovery files.

Node.js 26 LTS FAQ