Skip to main content
Image Python You do not write everything from scratch every time; most of the time you stand on a prebuilt image (FROM). Picking one comes down to two things: trust and variant.

​
Trust: three tiers

TierHow to spot itMaintainer
Docker Official ImagesNo user prefix (python, ubuntu), official badgeCurated by Docker
Verified Publisher”Verified Publisher” badge, vendor name in the pathReviewed commercial vendor
Community imagesFormat username/image, no badgeIndividual users, judged by downloads and reputation
How to confirm trust is covered in Docker Hub.

​
Python image variants

Take the official Python image as the example; toggle below to see the differences:

​
The Alpine trap

Alpine uses musl libc rather than glibc, which causes:
  • Prebuilt binary wheels on PyPI (manylinux, targeting glibc) fall back to source builds on Alpine, requiring gcc / musl-dev and each package’s C headers in the image, so build time soars and the final image may not be smaller.
  • numpy, scipy, pandas, PyTorch, TensorFlow and similar scientific / ML packages need self-compiling or unofficial packages on Alpine: not recommended.
  • Alpine suits pure Python (no C-extension deps), a hard size requirement, and willingness to accept the compile cost in a multi-stage build.

​
Rules of thumb for picking a version

Need scientific packages (numpy / pandas / scipy / torch)?
  → Yes → python:3.X (full) or python:3.X-slim + manually install build-essential
  → No  → python:3.X-slim (default)
          └→ Hard size requirement + confirmed no C extensions?
                → Yes → python:3.X-alpine (accept self-compiling)
  • Pin a major.minor tag (python:3.12-slim), not latest or python:3.
  • Default to slim, adding build tools yourself when compiling native packages.
  • bookworm = Debian 12, bullseye = Debian 11; use a codename tag (python:3.12-slim-bookworm) to lock the Debian version.

​
Next

Reference: hub.docker.com/_/python, Docker Official Images