Bits of .NET

🤖 The AI Prompt That Finds Exactly Why Your Image Is Bigger Than It Needs to Be

A Docker image that’s grown to several times the size it should reasonably be rarely has one obvious cause – it’s usually a handful of small, individually-reasonable-looking decisions (a base image that’s heavier than necessary, build tools left in the final layer instead of being discarded after a multi-stage build, a package manager’s cache never cleaned up, a COPY instruction that pulls in far more of the build context than the image actually needs) that add up quietly over the Dockerfile’s lifetime. This prompt asks an AI assistant to walk through a Dockerfile line by line looking specifically for that category of avoidable size.

📋 The Prompt

Here's our Dockerfile (and, if relevant, the .dockerignore file next to
it). Walk through it and identify specific, concrete opportunities to
reduce the final image size, including:

1. Whether the base image could reasonably be a smaller variant (an
   alpine or slim tag, or a distroless image) given what the
   application actually needs at runtime
2. Any build-time-only tools, compilers, or dependencies that end up
   in the final image layer instead of being isolated to an earlier
   stage of a multi-stage build and discarded
3. Package manager cache directories or temporary files that get
   created during a RUN instruction but never cleaned up in that
   same instruction (which matters because of how Docker layers work)
4. Whether .dockerignore is missing entries that would stop
   unnecessary files (version control metadata, local dependency
   folders, test fixtures) from being copied into the build context
   at all

For each finding, estimate roughly how much size impact it likely has
relative to the others, so the biggest wins are obvious.

Dockerfile:
[PASTE THE DOCKERFILE AND .dockerignore HERE]

✅ Why This Prompt Works

• Asking for a relative size-impact estimate per finding, even a rough one, turns a list of ‘things that could be better’ into something that can actually be prioritized – switching a base image is usually the single biggest win, and knowing that up front saves time compared to fixing a dozen small things first.
• Specifically checking whether a RUN instruction cleans up in the same instruction it creates cache or temp files in targets a subtle but very common mistake – because Docker layers are immutable once created, a cleanup command in a later, separate RUN instruction doesn’t actually shrink the image, only one combined in the same instruction does.
• Reviewing .dockerignore alongside the Dockerfile catches a frequently-overlooked cause of bloat that isn’t even visible in the Dockerfile itself – a large, unnecessary build context gets copied into intermediate layers via COPY instructions regardless of how clean the Dockerfile’s own instructions look.

⚠️ Where to Draw the Line

• Size estimates here are reasoning from general knowledge of how base images, package managers, and layer caching behave, not from actually building and measuring the image – running docker build with –progress=plain and comparing layer sizes directly afterward confirms which findings actually mattered most.
• A smaller base image isn’t automatically the right trade-off for every project – a slim or alpine variant sometimes means a different C library (musl vs glibc) that can introduce its own compatibility issues worth testing for before adopting it purely for size.