How do I shrink Docker images with multi-stage builds and distroless?

Short answer: a 1.2GB image ships your whole build toolchain to production — both slow and a big attack surface. A multi-stage build fixes both; you put only the artifact and the runtime in the final stage.

The root of the problem is singular: things that shouldn’t be there (compiler, package manager, shell) leak into production.

1. The multi-stage idea: a builder stage produces, the final stage only copies. Put the compiler and dependencies in the first stage and produce the artifact. In the final stage, COPY --from=builder only the binary/app + the runtime it needs to run. Build tools never enter the image.
2. For Go, the final stage can be scratch or distroless/static. The Go binary is self-contained (statically linked), so you get an image of a few MB. Distroless has no shell or package manager — smaller attack surface; when you need to debug, use the :debug variant.
3. PHP is more nuanced: the runtime is unavoidable. There’s no compiled binary in PHP; you need the PHP runtime + extensions. Target php:8.x-fpm-alpine, run composer install --no-dev in the build stage, and copy only vendor/ + the app into the final stage. You won’t hit a few MB, but you drop from hundreds to tens of MB.
4. Security matters as much as size. Run the container as non-root, exclude junk with .dockerignore, pin the base image by digest, and let the registry layer-cache the dependency stage so it isn’t refetched on every build.

Bottom line: I’d use multi-stage + distroless/static/scratch for Go, fpm-alpine for PHP, run non-root, and keep .dockerignore tight. That turns a 1.2GB image into tens of MB — faster CI/CD, smaller attack surface. I explain how image layers work and the .dockerignore logic from the ground up in the hub post; that setup lays the groundwork for this optimization.