No. A tag without a Debian codename follows the default release the image maintainers choose, and that can change. On the official Python image page we fetched, the bare slim tag was listed with the slim-trixie tags. If the operating system release matters to you, name the codename in the tag.
What the Python image page shows
The official Python image lists tags by variant and Debian codename. In the fetched listing, these tags shared a build:
3.15-trixie,3-trixie,trixie3.15-slim-trixie,3-slim-trixie,slim-trixie,3.15-slim,3-slim,slim
Meanwhile the bookworm variants had their own entries, such as 3.15-bookworm and 3.15-slim-bookworm, without the bare slim name. So at that moment, bare names mapped to trixie.
The page explains the naming. Tags with names like bookworm or trixie are Debian suite code names and indicate which release the image is based on. It recommends specifying one explicitly if you install additional packages, to minimise breakage when new Debian releases arrive.
Why that matters
Imagine a Dockerfile with FROM python:3.15-slim. Today it resolves to one Debian release. When the maintainers move the default to the next release, a rebuild pulls a different operating system under the same line. Library versions change, native extension builds change, and you did not edit anything.
That may be fine, since you get a newer base. It becomes a problem when it happens unplanned, on a Friday rebuild, in a service with no tests.
Variants and their tradeoffs
| Variant | Based on | Notes from the maintainers |
|---|---|---|
| Default (codename tag) | Debian, with many common packages | Described as the de facto image |
| Slim | Debian, minimal packages | Installing from source distributions may fail without build tools |
| Alpine | Alpine Linux, with musl libc | Smaller, but software with deep libc assumptions can hit issues |
Those notes come from the image page itself. If a pip install starts failing after you change variant, the first thing to check is whether the package needs compiling.
How to pin the release
- Add the codename to the tag, such as slim-bookworm or slim-trixie, in every Dockerfile.
- Add the digest if you need repeatable builds. Docker's guidance says tags are mutable and digests are not.
- Choose the moment you move codenames. Treat it as a planned change with a pilot service.
- Record the base in your image register or SBOM so you can search by release later.
Check what you actually run
Do not trust the Dockerfile alone. Read the operating system name and version from a scan or SBOM of the built image. Disagreements between the Dockerfile and reality are common in older services.
The same logic applies to other languages
Other official language images may name operating system releases in their tags too. Check each image page, since variants differ.
Where Safeguard fits
Safeguard's per image SBOM and container scan record the operating system release in the finished image, so you can see which services moved when a default changed. Try the free scan at https://gold.safeguard.sh/scan.
Quick check
Is the bare tag always the newest Debian?
Not necessarily. It follows the maintainers' default at the time. Read the current tag list to see what it maps to.
Should I use alpine to avoid this?
Alpine tags can carry a branch number in the name, which pins the branch, but musl libc brings its own compatibility questions. Pick for fit, not to dodge pinning.
Sources
Last reviewed: 19 October 2026.
