What is the difference between the slim and alpine tags?

A -slim tag is the Debian-based image with documentation and extra packages removed — it keeps glibc, so most binaries just work, while being smaller than the full image. An -alpine tag is built on Alpine Linux with musl libc, which is far smaller but can break glibc-only binaries and slow some package builds.

When should I use the scratch base?

Use scratch when shipping a fully static binary, typically from Go or Rust, that needs no operating system, shell or libc. You build in a toolchain image, then COPY the binary into scratch for the smallest possible final image. Note there is no shell, so you cannot exec into it for debugging.

Why pin a version instead of using latest?

The latest tag moves over time, so a build that worked today can break tomorrow when the underlying image changes. Pinning a specific version like node:22-slim or postgres:17 makes builds reproducible and lets you upgrade deliberately rather than by surprise.

Is the openjdk image still recommended?

The Docker official openjdk image is deprecated. For Java, prefer eclipse-temurin, which provides current JDK and JRE builds from the Adoptium project. Use a -jre tag for runtime-only images to keep them smaller than a full JDK.

Why use a multi-stage build?

A multi-stage build compiles your app in a heavy toolchain image, then copies only the resulting artifact into a small runtime base. The final image excludes compilers, source and build caches, which cuts size dramatically and reduces the attack surface.

Docker Official Image Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Choose the right Docker official image

Docker Hub’s official images are curated, regularly patched starting points for containers. This reference lists the most-used ones — base OS layers, language runtimes, databases and servers — with their typical tags, the base OS each variant uses, and notes on the traps that bite people, like Alpine’s musl libc.

How it works

A Dockerfile starts from a base image with FROM. Picking the right tag balances size, compatibility and build speed:

# multi-stage: build in a toolchain image, ship a slim runtime
FROM node:22 AS build
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM node:22-slim
WORKDIR /app
COPY --from=build /app/dist ./dist
CMD ["node", "dist/server.js"]

The -slim variant keeps glibc for compatibility while dropping extras; -alpine goes smaller still but uses musl, which occasionally breaks prebuilt binaries.

Tips and notes

Pin explicit versions for reproducible builds; avoid latest in production.
Reach for -slim first; only move to -alpine once you have confirmed your dependencies build and run under musl.
Use multi-stage builds so compilers and source never reach the final image.
For static Go or Rust binaries, a scratch or distroless base gives the smallest, most locked-down result.