How to Shrink a Docker Image From 1.2GB to 180MB
A practical guide to cutting Docker image size by 85% without touching app code: multi-stage builds, slim base images, layer ordering and .dockerignore.
A developer describes reducing a service's Docker image from 1.2GB to roughly 180MB without changing any application code. The largest gain came from multi-stage builds: separating the heavy build toolchain from the runtime image and copying only the compiled artifacts saved about 500MB alone. Switching from a full base image like node:20 to node:20-slim shrank things further, and for statically compiled languages, distroless or scratch images can go even smaller—though they lack a shell, which changes how debugging works.
Other impactful changes included reordering Dockerfile layers so dependency installation happens before copying source code, turning a four-minute rebuild into a twenty-second one thanks to better cache reuse. Adding a thorough .dockerignore file prevented .git history, node_modules, and local .env files from leaking into the build context and bloating layers. The writer also stresses combining install-and-cleanup commands into a single RUN layer, since deleting files in a later layer doesn't reclaim space from an earlier one.
The end result: image size dropped from 1.2GB to about 180MB, cold pulls went from 90 seconds to 12, and cached rebuilds fell from four minutes to twenty seconds. None of the techniques are exotic, but combined they turn a dreaded deploy step into a non-event—offering engineers low-risk, high-impact optimizations they can apply immediately.