Container builds: small runtime, explicit privilege

Operational decision

For a Go reconciliation worker, compile a static binary in a builder stage and run it as a nonroot numeric user in a small runtime stage. Add a .dockerignore that excludes local credentials, test reports, and version-control metadata; otherwise those files can enter the build context even when they are never copied into the final stage. Pin base images by digest for repeatability, then refresh them on a scheduled security cadence. Scan the final image and test it under the same user and filesystem permissions used in production. The sample is a pattern for a Go module whose main package is under cmd/reconciler; adjust the module path and base digest for the actual repository. A container process is still subject to network, capability, and host controls outside the Dockerfile.

FROM golang:1.25-alpine AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -trimpath -o /out/reconciler ./cmd/reconciler
FROM alpine:3.22
RUN addgroup -S app && adduser -S -G app app
COPY --from=build /out/reconciler /usr/local/bin/reconciler
USER app
ENTRYPOINT ["/usr/local/bin/reconciler"]

Cost and verification

A smaller image can reduce transfer time and vulnerability surface, but a second stage adds build configuration to maintain. Alpine can have compatibility implications for applications that need glibc; this static Go build avoids that specific dependency. Cached modules speed repeat builds, while stale base layers can retain fixed vulnerabilities. The shown tags are mutable and should be pinned to real digests in a production repository. Do not put secrets in build arguments or source files; use a secret mount for build-time access and keep secret material out of layers.

Common Mistakes

• Do not mistake a small image for a secured runtime.
• Do not include credentials in the build context.
• Do not pin a base image forever without an update process.

Connected lessons

• DevOps Tutorial
• Immutable artifacts and release provenance
• Kubernetes Deployment: rolling update capacity
• Secrets and configuration across the delivery path

Advanced follow-up

• Multi-architecture images: verify every platform behind one tag

Advanced follow-up

• Build secrets: keep credentials out of layers and exported caches