Base Images

Every image starts FROM a base, and that one line sets your security surface, your image size, and your debugging experience for the life of the image. The spectrum runs from full distro bases like ubuntu and debian, through slimmed variants, to minimal alpine, to distroless images that carry the runtime and your app but no shell or package manager, all the way to scratch, which is literally empty. Smaller bases mean less to attack and less to patch — and also less to debug with.

The trade is real in both directions, which is why "always use the smallest base" is wrong advice. A smaller base shrinks the attack surface and the bytes you ship, and it strips away the shell and tools you reach for when something breaks at 3am. The right choice depends on the app, the team's tolerance for ephemeral-debug-container workflows, and how much the size actually matters.

Official and Verified Images

Docker Hub's official images — python, postgres, nginx — are maintained by the registry and the upstream projects, scanned regularly, and documented. Preferring them over an arbitrary user's image is the first supply-chain decision you make, and the cheapest. A random someuser/python-fast may be faster to find and slower to regret: you inherit its unpatched vulnerabilities and unknown provenance the moment you build FROM it.

Full vs Slim

A debian or ubuntu base carries a complete userland — every coreutil, every locale, the docs, the package manager — which makes it easy to debug and large to ship. The -slim variants strip the docs, locales, and extras, cutting the base size sharply with little downside for most applications. A python:3.12 base runs close to 1 GB; python:3.12-slim is around 120 MB for the same Python.

For the vast majority of services, -slim is the sane default. You keep glibc and a real package manager — so installing a dependency or dropping into a shell still works — while paying a fraction of the size. It's the choice that asks the fewest questions.

Alpine and the musl Caveat

alpine is about 5 MB, built on musl libc and BusyBox instead of glibc and GNU coreutils. The size is genuinely tiny, but musl is not glibc, and that difference is not free. Precompiled binaries and Python wheels built against glibc can fail outright or segfault; DNS resolution and locale handling differ in subtle ways that surface as intermittent bugs rather than clean errors.

The failure mode that costs the most is the one that looks like a size win. You switch a Python service to alpine, the image drops to a tenth of its size, and three weeks later a compiled wheel that shipped fine on Debian segfaults under musl — and the hours spent diagnosing it dwarf the megabytes saved. Validate your actual dependencies on alpine before adopting it; the size is only a win if the app still runs.

Distroless

Google's distroless images contain the language runtime and your application and nothing else — no shell, no package manager, no coreutils. The attack surface and the size both shrink dramatically: there is no bash for an attacker to land in, and almost nothing to patch. The cost is the flip side of the same fact — there is no bash for you to exec into either, so debugging means ephemeral debug containers or solid logging rather than a shell prompt.

scratch and Static Binaries

A FROM scratch image is empty — no userland at all. A statically linked Go or Rust binary plus its TLS root certificates can be the entire image: a few megabytes, near-zero attack surface, nothing to exploit because there is nothing there but your binary. It only works for binaries that need nothing from the OS, which rules out anything dynamically linked against system libraries.

This is the extreme end of the spectrum, and the direction Driftwood's slim build moves toward in the Dockerfile chapter — not necessarily to scratch, but down the list as the app and the team mature enough to give up the in-image shell.