Docker images grow quietly. You start with a clean image, add a dependency here and a build tool there, and one day a simple web app ships as a one-gigabyte image. Large images are not just untidy. They slow down deploys, eat storage on free-tier registries and servers, and increase the time between pushing code and seeing it run. Shrinking them is one of the highest-value chores in container work, and most of the wins come from a few habits.

The biggest win is the multi-stage build. In a single-stage image, everything used to build the app stays in the final image: compilers, package managers, test tools, and intermediate files. A multi-stage Dockerfile builds the app in one stage and copies only the finished artefact into a second, minimal stage. A Node app that needed a full build environment can ship as a small runtime image, and a Go app can ship as a single static binary in a near-empty image. This one change often cuts an image by half or more.

Next, choose a smaller base image deliberately. Full operating-system images are convenient because they include every tool you might need, but slim variants and Alpine-based images remove most of that weight. Check what your app actually requires: a runtime, a few system libraries, and certificates are usually enough. If a slim image breaks your build, the missing piece is usually one package, and adding that package explicitly is better than carrying an entire distribution for it.

Layer order matters too. Docker caches each instruction, so put the steps that change least often, like installing dependencies, before the steps that change every commit, like copying source code. That way a small code change rebuilds only the last layers instead of reinstalling everything. Also clean up inside the same layer that creates waste: if you install packages and remove caches in separate instructions, the cache still lives in an earlier layer. Combine them, and the waste never ships.

Finally, inspect your images instead of guessing. Tools that list layers by size show exactly which step added the weight, and the answer is often surprising: a forgotten test fixture, a documentation folder, or a package cache. Add a .dockerignore file to exclude what the image never needs, such as local environment files, git history, and node modules that should be installed fresh. Rebuilding after these changes usually shows a dramatically smaller number.

Small images pay off everywhere: faster CI runs, faster deploys, cheaper storage, and quicker rollbacks when a release goes wrong. Aim for the smallest image that still runs your app correctly, measure before and after, and make image size a number your team notices. It is unglamorous work, but it is the kind of work that makes every deploy after it faster.

Shrinking an image once is satisfying; keeping it small is the harder part. Set a size budget for each image, a number your team agrees is reasonable, and check it in CI so a change that doubles the size gets noticed in review rather than in production. Most registries and CI tools can report image size, and a simple check that fails the build when an image crosses its budget turns a good intention into a rule that holds under deadline pressure.

Also revisit your images after major dependency changes. A framework upgrade, a new system library, or a copied example Dockerfile can quietly add hundreds of megabytes, and nobody notices until deploys slow down again. A quarterly review, comparing current sizes against the budget and checking layer breakdowns, catches that drift early. Small images are a habit, not a one-time fix, and the teams with the fastest deploys are usually the teams that treat image size as a metric worth watching.