Docker Official Image Reference

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.

Tag variants and what they mean

Every official image publishes several tag families. Understanding the pattern saves you from accidentally shipping a 1 GB image when a 25 MB one would do:

-slim strips documentation, man pages, and extra packages while keeping glibc, so almost every prebuilt native module still works. -alpine is smaller but uses musl libc — occasionally a prebuilt .node file or Python C extension compiled for glibc will fail silently or crash at runtime.

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.

Notable official images and their quirks

alpine — the base OS image for Alpine Linux. Tiny (~5 MB), but apk add is slow in CI because it re-fetches the package index on every build unless you cache the apk directory. Add --no-cache to avoid a cached stale index in the image layer.

debian / ubuntu — full OS bases. Use these when you need a familiar shell environment. Ubuntu LTS tags (ubuntu:24.04) are good starting points for images that need many system packages.

node — pin to a major version like node:22, not node:lts or node:latest, both of which will shift when a new LTS is released.

python — comes in full, slim, and alpine variants. Many scientific Python packages (numpy, scipy) ship pre-built wheels compiled for glibc, so -slim is usually the right tradeoff — small enough, no musl breakage.

postgres — the default tag runs the full Debian-based image. For development stacks postgres:17 is fine; for production, rely on your managed database service rather than a container.

nginx — nginx:alpine is a popular choice for serving static assets. It is under 10 MB and supports the full nginx feature set. Use nginx:1.27-alpine rather than nginx:alpine so you pin the version.

eclipse-temurin — the recommended Java image since the official openjdk image was deprecated. Use -jre tags for runtime-only containers; -jdk for build stages.

Tips and decision tree

1. Do you need glibc-dependent native modules? Use -slim. -alpine will bite you.
2. Is the binary fully statically compiled (Go, Rust)? Use scratch or distroless/static.
3. Do you need debugging tools (curl, bash, ps) in the final image? Use -slim. Never use them as a reason to ship the full image.
4. Are you pinning? Always pin a specific version. latest will change under you.
5. Are you using multi-stage builds? You should be — compile in a heavy toolchain image, copy only the artifact into the runtime base.