How to Shrink Docker Images: 6 Proven Techniques

— ny_wk

A bloated Docker image is slow to build, slow to push and pull, and a bigger attack surface. The difference between a 1.2 GB image and a 90 MB one is usually a handful of habits — not black magic. Here's how to trim images down without breaking your app.

1. Start from a smaller base image

Your base image sets the floor. Swapping a full ubuntu or node image for an -alpine or -slim variant can cut hundreds of megabytes instantly. Alpine is tiny (~5 MB); just test your dependencies, since it uses musl libc instead of glibc.

2. Use multi-stage builds (the biggest win)

Build your app in one stage with all the compilers and dev tools, then copy only the finished artifact into a clean, minimal final stage. Your shipped image never carries the build toolchain. For compiled languages this routinely turns a 800 MB image into tens of MB.

3. Collapse and order your layers

Each RUN creates a layer. Chain related commands with && and clean up in the same layer — installing packages and deleting the cache in separate layers still leaves the cache in the image. Put rarely-changing steps first so the cache is reused on rebuilds.

4. Clean package manager caches

After installing, remove the cache in the same RUN: apt-get clean && rm -rf /var/lib/apt/lists/* (Debian/Ubuntu) or apk add --no-cache ... (Alpine). Don't ship package indexes you'll never use at runtime.

5. Add a .dockerignore

Without it, the whole build context (.git, node_modules, logs, local env files) gets sent to the daemon and can sneak into your image. A good .dockerignore keeps the context lean and builds faster.

6. Only install what you need at runtime

Skip "recommended" extras (--no-install-recommends), don't install build-only deps in the final stage, and avoid dev/test packages in production images.

Key takeaways

• Pick a slim/alpine base image to lower the floor.
• Multi-stage builds are the single biggest reducer — ship only the artifact.
• Chain RUN steps and clean caches in the same layer.
• Use .dockerignore and install only runtime dependencies.

Frequently asked questions

What's the single most effective trick?

Multi-stage builds — they keep the build toolchain out of the final image, often cutting size by an order of magnitude.

Is Alpine always the right base?

Usually smaller, but its musl libc can cause subtle issues with some binaries. Test; -slim Debian images are a safe middle ground.

Why didn't deleting files reduce my image?

If you delete in a later layer than you created them, the data still lives in the earlier layer. Create and clean in the same RUN.

Does image size affect security?

Yes — fewer packages mean a smaller attack surface and fewer CVEs to patch.

Adopt these six habits and "why is my image a gigabyte?" stops being a question you ever have to ask.