How to Upgrade Node.js: Version Managers, Installers, Docker and CI

To upgrade Node.js, install the new version with the same tool that installed the old one (nvm or fnm, the nodejs.org installer, a package manager, or a new Docker base image), reinstall dependencies so native addons are rebuilt, run your tests, then update the version pins in .nvmrc, package.json, CI and Dockerfiles. Upgrade to an LTS line: on 11 October 2026 that is Node.js 24, or Node.js 26 once it enters LTS on 28 October 2026.

node -v                                  # what you run now
nvm install --reinstall-packages-from=current 24
nvm alias default 24
rm -rf node_modules && npm ci && npm test

The rest of this post covers each install method, the breaking changes that bite between majors, and rolling the upgrade through CI and production.

Start by finding the version and, more importantly, how it was installed, because upgrading with a different tool leaves two Node.js installs fighting over PATH.

node -v
npm -v
node -p process.versions     # V8, OpenSSL and module ABI versions
which -a node                # Windows: where node

A path under ~/.nvm or fnm's directory means a version manager; /opt/homebrew or /usr/local/Cellar means Homebrew; /usr/bin/node usually means apt or yum; C:\Program Files\nodejs means the Windows installer.

Odd-numbered lines such as 25 never get LTS, so skip them in production. If you are on 20 or older, Node.js 24 gives you until April 2028; if the upgrade lands after 28 October, Node.js 26 buys another year. Our Node.js end of life post has every date and the cloud runtime deprecations.

Version managers install each Node.js version side by side in your home directory, so switching back is one command. nvm (v0.40.8 at the time of writing) is the most common:

nvm ls-remote --lts | tail -3
nvm install --reinstall-packages-from=current 24
nvm alias default 24
node -v

--reinstall-packages-from copies your global npm packages across; without it, globally installed CLIs disappear after the switch. fnm is faster and also reads .nvmrc and .node-version, switching automatically when you set it up with fnm env --use-on-cd:

fnm install 24
fnm default 24

Volta users should note its README now says it is unmaintained and recommends migrating to mise, where the equivalent is mise use node@24.

• Official installer. The macOS and Windows installers from nodejs.org upgrade in place. Pick the LTS download, not Current.
• Homebrew. brew upgrade node moves you to the newest release, which is Node.js 26 and not yet LTS. To stay on 24, install the versioned formula; it is keg-only, so put it on your path:

brew install node@24
echo 'export PATH="$(brew --prefix node@24)/bin:$PATH"' >> ~/.zshrc

• Debian and Ubuntu. Distribution packages often lag several majors behind; check apt-cache policy nodejs. NodeSource publishes a repository per major line:

curl -fsSL https://deb.nodesource.com/setup_24.x -o nodesource_setup.sh
sudo -E bash nodesource_setup.sh
sudo apt-get install -y nodejs

• Windows package managers. winget upgrade OpenJS.NodeJS.LTS, or choco upgrade nodejs-lts with Chocolatey. Open a new terminal afterwards so PATH is reloaded.

In containers the upgrade is the FROM line. Pin the major version and the distribution, because floating tags such as node:lts move to the next major when it becomes LTS:

FROM node:24-bookworm-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]

Run npm ci inside the image rather than copying node_modules from a laptop: native addons are compiled for a specific Node.js version and C library, and an Alpine image uses musl rather than glibc. Trixie-based tags such as node:24-trixie-slim also exist if you are moving the OS forward at the same time. AceMQ's Docker support team handles base-image upgrades and image hardening across a fleet.

Record the new version where every tool will see it:

echo "24" > .nvmrc

// package.json
"engines": { "node": ">=24 <25" }

# GitHub Actions
- uses: actions/setup-node@v7
  with:
    node-version-file: .nvmrc

The engines field is advisory: npm only warns on a mismatch unless engine-strict=true is set in .npmrc. Set it if you want installs on the wrong version to fail.

• Native addons. Each major changes the module ABI (NODE_MODULE_VERSION 115 on Node.js 20, 127 on 22, 137 on 24, 147 on 26). An addon built for the old one fails with an error that it was compiled against a different Node.js version. Delete node_modules and run npm ci, or npm rebuild, and check that packages with prebuilt binaries publish builds for the new version.
• OpenSSL. Node.js 17 moved to OpenSSL 3.0, which rejects some old algorithms and key sizes with ERR_OSSL_EVP_UNSUPPORTED; --openssl-legacy-provider is a temporary workaround, not a fix. Node.js 24 moved to OpenSSL 3.5 in 24.5.0. Test TLS connections to old internal services and anything that signs or hashes.
• DNS. Also since Node.js 17, dns.lookup() returns addresses in the order the resolver gives them, so localhost can resolve to ::1 and miss a service listening only on 127.0.0.1.
• npm major. Node.js 20 and 22 ship npm 10; 24 and 26 ship npm 11. Read the npm changelog if CI scripts parse npm output or rely on old flags.
• Removed APIs. Node.js 24 runtime-deprecates url.parse() and removes tls.createSecurePair; Node.js 25 removed fs.F_OK and its siblings; Node.js 26 removes the deprecated writeHeader() alias in node:http and the legacy _stream_* modules. Run your tests on the current version with --throw-deprecation first to surface deprecated calls.
• Types and tooling. Move @types/node to the matching major, and upgrade build tools old enough to hit the OpenSSL change.

1. Add the new version to the CI matrix next to the old one and fix failures until both pass.
2. Switch the default: .nvmrc, engines, Dockerfiles and serverless runtimes (AWS Lambda offers nodejs24.x and nodejs26.x).
3. Deploy to staging, then canary a slice of production. Watch memory, garbage-collection pauses, latency and error rates: a new V8 can change all four.
4. Roll out fully, keep the previous image ready for rollback, then remove the old version from the matrix.

Sometimes the blocker is a vendor SDK, a native module with no new build, or a frozen release. Running an end-of-life line unpatched is the worst option. AceMQ's OSSeva platform backports security fixes, including V8 and libuv CVEs, to Node.js 14, 16, 18 and 20 on a quarterly cadence, delivered as signed Docker images and apt, yum or binary packages, so you can schedule the upgrade instead of rushing it. It is the same patch-or-upgrade trade-off we describe for Spring Boot past end of life; see end-of-life support for the other runtimes we cover.

• Node.js Release Working Group: release schedule
• Node.js: Node.js releases
• Node.js: release index (bundled npm, OpenSSL and module versions)
• Node.js: v17.0.0 release notes (OpenSSL 3.0, dns.lookup order)
• Node.js: v24.0.0 release notes
• Node.js: v24.5.0 release notes (OpenSSL 3.5)
• Node.js: v25.0.0 release notes
• Node.js: v26.0.0 release notes
• nvm: Node Version Manager
• fnm: Fast Node Manager
• Volta: README (unmaintained notice)
• NodeSource: Node.js binary distributions
• Docker Hub: official Node.js images
• npm: package.json engines
• GitHub: actions/setup-node
• AWS: Lambda runtimes
• OSSeva: Node.js extended support