How to Build Tiny, Clean, and Maintainable Docker Images for Go Services

Why Docker Images for Go Services Often End Up Bloated

Many developers wonder why their Go service images quickly reach hundreds of megabytes and are uncertain whether to use scratch or distroless bases. The root cause is a shallow understanding of container images, treating them as a simple box that must contain everything.

Typical Naïve Dockerfile and Its Consequences

FROM golang:1.22
WORKDIR /app
COPY . .
RUN go build -o app
CMD ["./app"]

This approach is not wrong; it reflects the intuition of bundling the program with everything it might need, resulting in images close to 1 GB, retaining the compiler, source code, and a large attack surface.

Adopting the Builder Pattern with Multi‑Stage Builds

FROM golang:1.22-alpine AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app
FROM alpine:3.19
COPY --from=builder /src/app /app
CMD ["/app"]

The key benefit is not merely size reduction but a clear separation between build‑time and run‑time environments, ensuring that build tools do not become part of the final artifact.

Further Slimming with Alpine and the Question of a Linux Distro

After shrinking the image to around 20 MB with Alpine, a critical question arises: if a Go binary is statically compiled, do we still need a Linux distribution?

CGO_ENABLED=0

No reliance on system dynamic libraries

For such binaries, the answer is generally no; the base OS adds unnecessary weight.

Using Scratch for the Minimal Image

FROM golang:1.22-alpine AS builder
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app
FROM scratch
COPY --from=builder /src/app /app
ENTRYPOINT ["/app"]

The resulting image contains only the compiled binary, no shell, libc, or package manager, and its attack surface approaches the theoretical minimum. This is not an extreme optimization but a conscious decision to eliminate unnecessary dependencies.

Practical Gaps When Using Scratch

HTTPS : CA certificates must be copied manually.

Timezone : Zoneinfo data must be added explicitly.

Debugging : Requires a local debugging image or a sidecar container.

Thus, the minimization targets the runtime environment, not the engineering capability.

Distroless as a Balanced Middle Ground

If scratch feels too aggressive, the distroless base offers a mature compromise.

Provides CA certificates and timezone data.

Omits shell and package manager.

Behaves predictably.

It sacrifices a bit of the “ultimate minimal” size in exchange for lower cognitive overhead for the team.

A Simple Maturity Model for Container Image Practices

L1 : Image is a “catch‑all” box.

L2 : Build and runtime are separated (builder pattern).

L3 : Treat image weight and dependencies like a systems‑engineering problem.

L4 : Minimal images become the natural outcome of the engineering process.

The image size is a symptom; the underlying mindset shift is the real driver.

Key Takeaways for Building Go Service Images

Start with multi‑stage builds from day one, even if the image is not tiny yet.

Clearly distinguish between dependencies you truly need now and those that are merely optional.

Treat the container image as a long‑term asset rather than a one‑off delivery artifact.

These practices won’t instantly boost performance or stability, but over time they reduce hesitation to modify services and help maintain a disciplined, low‑complexity system.