image-optimization

Image Optimization

Size and build time are the same problem viewed from two angles: both come from carrying more into the image, and into the build, than the running application needs. A slow build is usually a large one — the layers you push are the layers a runner had to pull, unpack, and cache too.

Optimize by removing, not by compressing after the fact. The fastest layer to pull is the one that was never built.

1. Choose the smallest base that still lets you debug

scratch and distroless bases produce the smallest, lowest-attack-surface images, but they ship without a shell — a production incident that needs exec-ing in becomes much harder. A distro-based "slim" variant is usually the right default: small enough to matter, still debuggable. Reserve scratch for statically-linked binaries (Go, Rust) where you genuinely never need a shell inside the container, and keep a debug-variant image or an ephemeral debug container available as a sidecar for when you do.

• Default to -slim or distroless for interpreted-language runtimes.
• Use scratch only for fully static binaries with no runtime dependency on libc or a shell.
• Keep a debug path (ephemeral containers, sidecar) rather than adding shell tools "just in case."

Done when: the base is the smallest variant that still supports your actual debugging workflow.

2. Collapse and reorder layers deliberately

Every RUN, COPY, and ADD is a layer, and layers do not shrink when a later layer deletes their contents — deleting a file in layer 5 does not reclaim the space it took in layer 3. Chain related commands with && so temporary files never persist as their own layer, and clean package manager caches in the same RUN that created them:

RUN apt-get update && apt-get install -y --no-install-recommends curl \
    && rm -rf /var/lib/apt/lists/*

Layer order still matters for cache reuse (see containerization), but here the goal is layer count and content — fewer, tighter layers pull and unpack faster regardless of cache state.