For production, pin a supported even-numbered major line with a variant, such as node:24-slim, and rebuild on a schedule. A floating lts tag moves to a new major when the project promotes one, and a fully exact tag stops receiving patches until you change it yourself.
What the tags mean
The official Node.js image publishes several kinds of tag for the same release. For the current Active LTS line, the Docker Library page lists tags such as the major number, the minor, the full patch version, a codename, and lts. Variants add a suffix, for example slim, alpine or a Debian release name.
That gives you a spectrum, from loosest to tightest:
| Tag style | Example | Moves when |
|---|---|---|
| Floating LTS alias | lts-slim | A new major is promoted to LTS |
| Major line | 24-slim | Each patch and minor release |
| Minor line | 24.22-slim | Each patch release |
| Exact version | 24.22.0-slim | Never, until you edit it |
| Digest | 24-slim@sha256 plus hash | Never, immutable content |
Why the floating alias is risky
The Node.js release process promotes an even-numbered line to LTS each autumn. The Release working group README lists the current picture: 22 in Maintenance LTS, 24 in Active LTS, and 26 as Current, with 26 scheduled to start its Active LTS phase on 28 October 2026. The README itself says dates are subject to change.
So a floating lts alias could jump a major version soon after that. A major bump can change behaviour in dependencies and native add-ons. A surprise upgrade in an unattended rebuild is a poor way to find that out.
Why exact is not automatically safer
A fully pinned tag gives repeatable builds, but it only helps if you rebuild. A tag that stays frozen for months misses patch releases of Node.js and of the operating system layer. Docker's own build guidance says tags are mutable, and suggests pinning to a digest when you want a guaranteed image, then updating your tags and digests on a schedule.
A practical middle path:
- Pin the major and variant in the Dockerfile.
- Pin the digest too if you want exact reproducibility, and let an update bot or a scheduled job propose new digests.
- Rebuild at least weekly so patch releases arrive.
- Fail the build if the line is near its end of life.
Check support dates before you choose
Do not start a new service on a line that is about to leave support. The Release README lists end-of-life dates for each line, 22 on 30 April 2027 and 24 on 30 April 2028 at the time of writing. Check the current table rather than trusting this post, since the project says dates may move.
Where Safeguard fits
Whichever tag you pick, the base image and your dependencies change over time. Safeguard's continuous monitoring and dependency scanning can rescan what you have already shipped when a new advisory appears, and policies can flag components past their support window. Try the free scan on a repository.
Quick check
Is the lts tag the same as the current major?
The Docker Library page lists lts as an alias for the current Active LTS line at the time of writing. It changes when the project promotes a newer line, which is the reason to avoid it in production.
Should I use an odd-numbered Node.js release in production?
The Node.js release policy says odd-numbered lines are not promoted to LTS, so they do not get the long support phases. Most production services use even-numbered LTS lines.
Sources
- Node.js official image tags, Docker Library docs
- Node.js Release working group README
- Docker build guidance, pin base image versions
Last reviewed: 19 October 2026.
