Nonceworks

Node 26 becomes node:lts on 2026-10-28: no corepack, no yarn, Debian 13

Written 11 October 2026

Written 2026-10-11 for teams that build from node:lts, node:lts-slim or node:lts-alpine, or install lts/* in CI. Node.js 26 becomes LTS on 2026-10-28 (nodejs/Release schedule). The script that writes the Docker tags gives the lts tags to the line that is LTS on the day it runs (docker-node stackbrew.js). Last year the same move, to Node 24, was merged into Docker's official images on 2025-10-28 at 21:41 UTC, the day Node 24 became LTS (official-images#20176), and the docker-node README warns that the image builds "can take several hours to complete" (Release Availability). On 2026-10-11, node:lts-slim was node:24-slim (digest d6aa754f16b3).

What changes

Measured on 2026-10-11 in today's node:lts-slim and in node:26-slim (digest 193fe51b64e7):

node:lts-slim today node:26-slim
Node.js 24.21.0 26.11.1
npm 11.19.0 11.20.0
corepack 0.36.0 not installed
yarn 1.22.22 not installed
Debian 12.15 13.7
glibc 2.36 2.41
NODE_MODULE_VERSION 137 147
  • corepack. The Node.js project stopped shipping it with Node 25 ("build: stop distributing Corepack", nodejs/node#57617, in 25.0.0), so the Node 26 images have none.
  • yarn. "Yarn v1 is not bundled into node images as of Node.js 26.0.0" (docker-node README, from docker-node#2422, merged 2026-03-24).
  • Debian. The default Debian for Node 26 images is trixie (13); for Node 24 it is bookworm (12) (docker-node versions.json). So node:lts and node:lts-slim change OS release on the same day. node:lts-alpine stays on Alpine 3.24. Between our fixture's two builds, on today's node:lts-slim and on node:26-slim (corepack 0.36.0 installed from npm on both), the canary's package diff showed 86 packages changed, 8 added and 17 removed, yarn, gpgv and e2fsprogs among the removed.
  • Node itself. Code that goes from 24 to 26 also takes the breaking changes of 25.0.0 and 26.0.0. The 26.0.0 release, for example, removed http.Server.prototype.writeHeader() and the legacy _stream_* modules (26.0.0 changelog).

Who breaks, and how to tell

corepack enable in a Dockerfile. The build stops at that step. This is our fixture, FROM node:lts-slim with RUN corepack enable && pnpm install, built on node:26-slim in the canary's public run on 2026-10-11:

 > [4/4] RUN corepack enable && pnpm install:
0.041 /bin/sh: 1: corepack: not found
ERROR: failed to build: failed to solve: process "/bin/sh -c corepack enable && pnpm install" did not complete successfully: exit code: 127

yarn used without installing it. Same shape: yarn: not found, exit code 127.

CI on lts/*. node-version: lts/* in actions/setup-node, or nvm install lts/*, picks the newest LTS line, which becomes 26. Node's own release tarballs no longer contain corepack (nodejs/node#59835), so a later corepack enable step fails too.

Native addons. NODE_MODULE_VERSION goes from 137 to 147, while Node-API stays at version 10 in both. Node-API addons carry over: better-sqlite3 13.0.3, installed on Node 24, loaded on Node 26 in our test. An addon built against Node's own ABI needs a build for 147, and the slim images have no python3, make or g++ to compile one (we checked both).

The fixes

The corepack and yarn lines below were run on today's node:lts-slim and on node:26-slim on 2026-10-11.

Stay on Node 24 for now: FROM node:24-slim (or node:24, node:24-alpine). Node 24 moves to maintenance on 2026-10-20 and reaches end of life on 2028-04-30.

Install corepack before you enable it. 0.36.0 is the version Node 24.21.0 bundles. Our fixture passes with this line on node:lts-slim today and on node:26-slim, and in a node:26-slim container corepack 0.36.0 ran the yarn version that a packageManager field asked for (4.9.2).

RUN npm install -g corepack@0.36.0 && corepack enable && pnpm install

Yarn 1 without corepack. A plain npm install -g yarn@1.22.22 fails on today's node:lts-slim with EEXIST: file already exists on /usr/local/bin/yarn, because the Node 24 images still bundle yarn. This line does nothing there and installs 1.22.22 on Node 26:

RUN command -v yarn >/dev/null || npm install -g yarn@1.22.22

Node 26 on Debian 12: FROM node:26-bookworm-slim, which exists today. The tag script gives the LTS line an lts-<variant> tag for each of its variants, and Node 26 has bookworm-slim, so after the move node:lts-bookworm-slim is Node 26 on Debian 12.

CI: pin node-version: 24 in actions/setup-node until the jobs pass on 26, or run npm install -g corepack@0.36.0 before corepack enable.

Check before the date

The upgrade canary has a preview mode: it rebuilds a copy of your Dockerfile with node:lts moved to node:26, keeping the variant (node:lts-slim becomes node:26-slim), and runs the same checks on the copy: clean build, every executable's libraries, start, package diff.

./canary.sh --flip-preview --ready-url http://localhost:3000/health .

In a workflow, set flip-preview: "true" on the Action, as in the ubuntu-latest note. The CLI exits 3 when today's build passes and the preview fails; --flip-warn-only reports the preview without failing the job, and --flip-plan prints the substitutions without building.

The start check matters as much as the build. On 2026-10-10 the OpenZeppelin Relayer's main branch built without an error after Wolfi's openssl-dev moved to OpenSSL 4, and its binary then exited 127 with libssl.so.4: cannot open shared object file. The library and start checks failed it; a branch that pins OpenSSL 3.6 passed them on two runs 15 hours apart. The preview runs those checks on the Node 26 copy too, so it also catches an image that builds and then does not start.

Limits

  • amd64 only.
  • The digests above are from 2026-10-11. The LTS release on 2026-10-28 is a new 26.x, so the numbers in the table will move a little.
  • We measured the slim images. The default images (node:lts, node:26) follow the same Debian rule in versions.json; we did not build on them.

Sources