Node 26 error: libatomic.so.1 cannot open shared object file

Node 26 became the LTS release on October 28, 2026 (26.13.0), so this is the week a lot of servers, CI jobs and Docker images move to it from Node 24. On a minimal Linux system, the first thing many of them will print is:

node: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

Nothing is wrong with your code or your Node download. Since Node 25, the official Linux binaries need one more system library, libatomic, and many minimal systems don’t have it. The Node 26 LTS release notes say so in one sentence: the binaries are “linked against libatomic, which may need to be installed separately depending on your Linux distribution”.

I checked the binaries themselves. readelf -d lists libatomic.so.1 as a dependency of node 26.12.1, on both x64 and arm64. It isn’t in the list for node 24.22.1. The LTS release, 26.13.0, lists it too.

Which systems fail

I unpacked the official node-v26.12.1-linux-x64 and node-v24.22.1-linux-x64 tarballs and ran each one in clean Docker images, with nothing installed first:

Every plain base image failed, and every one ran Node 24 without complaint. The official node:26 image is fine because it ships the library. The arm64 binary failed the same way in debian:bookworm-slim on an arm64 runner.

In CI, this usually shows up as exit code 127, the same code a missing command gives, which makes it easy to misread as “node isn’t installed”.

Why npm shows the same error

Running npm -v gave a shorter version of the error:

node: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

npm is a script that starts node, so it’s node that fails, and npm never runs. Fixing node fixed npm too.

The fix: install libatomic

In Docker: copying node into a slim image

A common way to hit this is a multi-stage Dockerfile that copies only the node binary out of the official image into a smaller base:

FROM node:26-bookworm-slim AS n
FROM debian:bookworm-slim
COPY --from=n /usr/local/bin/node /usr/local/bin/node

This worked with node:24. With node:26, the container failed on start with the libatomic.so.1 error, because the binary came across without the library. gcr.io/distroless/cc-debian12 failed the same way.

FROM node:26-bookworm-slim AS n
FROM debian:bookworm-slim
COPY --from=n /usr/local/bin/node /usr/local/bin/node
COPY --from=n /usr/lib/x86_64-linux-gnu/libatomic.so.1 /usr/lib/x86_64-linux-gnu/

On October 28, there was no gcr.io/distroless/nodejs26-debian12 image yet; pulling it returned not found.

nvm says it worked, then node fails

With nvm 0.40.3 in debian:bookworm-slim, nvm install 26 downloaded Node, matched the checksum and printed Now using node v26.12.1, with exit code 0. The very next node -v failed with the libatomic.so.1 error. nvm installs the same official binary, and it doesn’t check whether that binary can start.

Systems that weren’t affected

• The official node:26 Docker images. node:26-bookworm-slim already contains libatomic.so.1.
• GitHub-hosted runners. ubuntu-latest already has libatomic.so.1 installed, so actions/setup-node on the runner itself is fine. Only containers and self-hosted machines built from minimal images are at risk.
• Alpine is a separate problem. In node:26-alpine, the official glibc tarball didn’t run at all (not found), for Node 24 as well. That’s the musl vs glibc split, not libatomic. Use the node:26-alpine image’s own node instead.

How this was tested

October 28, 2026, on GitHub Actions: ubuntu-latest (x64) and ubuntu-24.04-arm (arm64) runners with Docker. The official Node 26.12.1 and 24.22.1 Linux tarballs were downloaded from nodejs.org and mounted into each image without installing anything first. Each image then got its distro’s libatomic package, and the same binaries ran again. The Docker cases built real multi-stage images. Node 26.13.0, the LTS release itself, changes only release metadata after 26.12.1, according to its release notes, and its binary lists libatomic.so.1 too (checked October 29). The scripts and the full output are public.