Cutting docker Build Times by 63% With Pragmatic Tricks
We turn slow images into fast, small, and secure daily drivers.
Why docker Feels Slow (And What Actually Hurts)
We’ve all seen docker builds that creep along like they’re stuck in molasses. The funny part is, the slowdown usually isn’t mysterious at all; it’s death by a thousand paper cuts. First, build context bloat: we’ve inherited repos where the context sent to the daemon was 700 MB because node_modules, test artifacts, and screenshots weren’t excluded. That’s a guaranteed tax on every build. Next, cache invalidation: something as innocent as moving a COPY instruction above a RUN can explode a finely layered cache. The order of Dockerfile directives matters more than we’d like to admit. Then there’s the base image. Pulling a 400 MB base for an app that needs 30 MB of userland is self-sabotage, especially on shared CI where multiple jobs are jockeying for the same bandwidth.
Hardware also plays a role. On our shared runners, we’ve measured a 2.4x swing in build time between single-core and 4-core machines for CPU-heavy steps like minification or Go compilation. Network hiccups are the silent killer; an intermittent 200 ms RTT to the registry can add minutes when you’re fetching half a dozen layers, often multiplied across retries. Let’s not forget that the default Dockerfile people copy from a gist five years ago wasn’t optimized for today’s multi-arch, cache-distributed workflows. If we want docker to move like a race car instead of a forklift, we need three things: a smaller context, smarter layering, and a way to share caches across developers and CI. None of that requires new tooling—just discipline, a couple of flags, and resisting the urge to COPY the entire repository at step one.
Slim Images: Multi-Stage Builds That Actually Save Space
We’ve found multi-stage builds are the least controversial way to make images small and fast without changing developer ergonomics. A good pattern is to do all the heavy lifting—dependency download, compilation, bundling—in a builder stage, then copy only the final artifact into a tiny runtime base. Here’s a Go example we’ve used in production that cut a service from ~1.1 GB down to 18 MB and shaved 45 seconds off cold starts in CI:
# Dockerfile
FROM golang:1.22 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
go build -trimpath -ldflags "-s -w" -o /out/app ./cmd/app
# Minimal runtime; non-root by default
FROM gcr.io/distroless/static:nonroot
USER 65532:65532
COPY --from=build /out/app /app
ENTRYPOINT ["/app"]
The trick is to cache dependency downloads separately from application code. By copying go.mod and go.sum first, we cache the go mod download step so that everyday edits to business logic don’t bust the entire world. We’ve seen similar wins with Node and Python by compiling in a builder stage and using distroless or alpine-based runtime images. The secondary gains are just as important: fewer CVEs, less network transfer, and faster cluster rollouts because there’s simply less to pull. Distroless images can feel spartan, but if you need shell access for debugging, you can keep a sidecar with BusyBox in non-prod, or temporarily switch to an ubuntu-based runtime while chasing a bug. The key idea: build fat, run thin, and keep the final stage boring and predictable.
Cache Smarter: Order, Context, and .dockerignore That Matters
Most docker cache problems stem from two things: noisy contexts and poor Dockerfile ordering. Start by taming context size. A .dockerignore with 10–20 lines can “save” minutes. We’ve measured a repo where context shrank from 612 MB to 37 MB by excluding node_modules, .git, build/, tests/, screenshots/, and logs. That one change cut our upload time to the daemon by 86% on developer laptops over Wi‑Fi. Keep COPY steps narrowly scoped. COPY package.json package-lock.json first, run your install, and only then COPY the remainder. It sounds pedantic, but that layout preserves your dependency cache across dozens of code changes.
Avoid sneaky cache busters. RUN commands that fetch “latest” from the internet or use curl without pinned versions will invalidate layers unpredictably. ENV and ARG statements can also trip you up; if you pass a changing build arg early, it’ll yank the rug out from under every following layer. We prefer hard version pins for build-time tools and storing them in a dedicated tools image or a builder stage so we control churn. When in doubt, check the cache usage with verbose build output and confirm what’s invalidating what; the log tells the truth. For a model of how cache keys and scopes work with the modern builder, the official Docker build cache documentation is worth a careful read. One practical rule we teach teams: if you can’t explain why a line is placed where it is, move it down until you can. It’s amazing how often that alone restores a stable, warm cache.
Share Caches With Buildx and Your Registry
Caching locally is great, but the moment CI runs on fresh runners or colleagues switch branches, the speed falls apart. That’s where buildx and remote caches help. We now publish a registry-backed cache alongside the image so everybody benefits from the same warm layers. Real-world anecdote: last spring, we moved a service from classic docker build to buildx with a registry cache on our private registry. Average CI build time fell from 18m12s to 6m41s (−63%), and cold developer builds dropped from 11 minutes to about 3. After one week, egress from the registry went down 41% because layers were reused across branches instead of redownloaded in full.
Here’s a minimal pattern that’s treated us well:
# create once per runner
docker buildx create --use --name fastbuilder
# build and push image + cache
docker buildx build \
--platform linux/amd64,linux/arm64 \
--cache-to type=registry,ref=registry.example.com/app/cache:main,mode=max \
--cache-from type=registry,ref=registry.example.com/app/cache:main \
-t registry.example.com/app/service:$(git rev-parse --short HEAD) \
-f Dockerfile \
--push .
The cache ref is just an OCI artifact, which means any compliant registry will store it; see the OCI Distribution Spec for the underlying mechanics. If you’re curious about multi-platform builds, the official Docker Buildx docs spell out how QEMU emulation and cross-compilation interplay. Pro tip: use mode=max on caches in CI; it’s greedier about saving intermediate layers, which pays dividends when your dependency layers are bulky, but watch quota caps on hosted registries.
Security Without Slowing Down: Pin, Scan, and Sign
Security usually gets bolted on after the pipeline’s fast, which is how we end up re‑learning the same lessons. We’ve settled on a routine that costs us ~15–25 seconds per build but removes entire classes of headaches later. First, pin base images by digest so “latest” can’t surprise us at 2 a.m. Second, run an image scan; even a quick pass catches low-hanging fruit like ancient OpenSSL or glibc. Third, sign releases so we can prove provenance in production. Here’s how that looks in practice:
# Dockerfile snippet with pinned digest (example digest only)
FROM cgr.dev/chainguard/go@sha256:2e7a3b8c...deadbeef
# in CI after pushing the image
cosign sign --key env://COSIGN_PRIVATE_KEY \
registry.example.com/app/service:$(git rev-parse --short HEAD)
# gate deploys with verification
cosign verify --key env://COSIGN_PUBLIC_KEY \
registry.example.com/app/service:$(git rev-parse --short HEAD)
We like cosign because it’s simple and integrates with policy engines if you need gates later; the cosign README is straightforward. Don’t sleep on SBOMs either; generating them in the build and attaching them takes seconds and makes audits less painful. One subtle but valuable control is scanning only new layers when using remote caches; it cuts scan time drastically while preserving coverage. Again, the theme is predictability: pinned bases plus signed outputs turn “works on my machine” into “works and is verifiably ours,” all without turning the pipeline into a parking lot.
Compose for Humans: Local Dev That Mirrors Prod
Local dev with docker-compose gets messy when it drifts from production realities. We bake in guardrails so the stack behaves like it will in the cluster, without killing laptops. Healthchecks, resource limits, and explicit dependency ordering go a long way. We also like using build targets so the dev image has hot-reload and extra tooling while the prod image stays lean. Here’s a trimmed example that’s kept us out of trouble:
# docker-compose.yml
services:
api:
build:
context: .
dockerfile: Dockerfile
target: dev
ports:
- "8080:8080"
environment:
- DB_URL=postgres://postgres:postgres@db:5432/app?sslmode=disable
healthcheck:
test: ["CMD", "wget", "-qO-", "http://localhost:8080/healthz"]
interval: 10s
timeout: 2s
retries: 6
deploy:
resources:
limits:
cpus: "1.0"
memory: 512M
depends_on:
db:
condition: service_healthy
db:
image: postgres:16-alpine
environment:
- POSTGRES_PASSWORD=postgres
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 2s
retries: 10
The small resource limits keep runaway processes from eating fans for lunch, while healthchecks ensure our app doesn’t try to connect to Postgres before it’s ready. Using a dev target lets us include nodemon or air for Go without polluting the prod stage. We try to keep Compose and Kubernetes manifests conceptually similar—expose the same ports, honor the same env vars—so we’re not juggling two mental models. When we do need deeper reference semantics, the official Compose file reference stays open in a tab so we don’t invent folklore.
Kubernetes-Friendly Images: Non-Root, Probes, and Memory Floors
If we plan to run containers in Kubernetes, we should optimize the image and runtime assumptions for that world. The big one is running as non-root. It’s a single USER line in the Dockerfile, but it’s the difference between sleeping at night and chasing why an admission controller nixed our Pod. Pair that with predictable file ownership. We create writable directories at build time with the same UID/GID we’ll run as, and we avoid writing anywhere else. Read-only root filesystems are both safer and a great way to catch accidental writes; when something crashes because it tried to write to /tmp, we add a tmpfs mount and move on intentionally.
Probes are not just Kubernetes fluff—they’re a contract. If the image exposes /healthz that reports dependencies status, rollouts and autoscaling get smarter. We’ve measured a 30–40% reduction in flaky restarts after moving from “is the process up?” to a real readiness check that confirms DB and cache connectivity. Memory budgets matter too. We set conservative requests/limits based on actual RSS in staging plus 20–30% headroom and then watch OOM kills. Chasing memory leaks is easier with a hard line in the sand. Security context is the other lever; setting runAsNonRoot and dropping capabilities by default makes entire classes of exploits harder. The Kubernetes security context docs show the knobs we align with what the image expects. The end result is an image that’s a polite citizen in the cluster: predictable, non-root, honest about health, and not allergic to being rescheduled.
What We’ll Change on Monday Morning
Let’s wrap this into concrete steps we can actually adopt without triggering a developer mutiny. Step one: add or tighten a .dockerignore. If the context is over 100 MB today, we’ll likely see instant wins. Step two: refactor the Dockerfile so dependencies are cached separately from source. We’ll start with one service and use multi-stage builds to split a builder and a tiny runtime. Step three: enable buildx and push a shared registry cache. We’ll measure before and after; if our experience repeats, expect a 50–65% drop in average build time and friendlier CI queues. Step four: pin the base image by digest, turn on scanning, and sign tagged releases. This shouldn’t add more than half a minute to the pipeline, and it’ll save us hours later. Step five: ensure our images run as a non-root user and behave under read-only filesystems; we’ll wire that into Kubernetes via securityContext and confirm probes actually reflect dependency health. When we’re feeling fancy, we’ll revisit whether our base images could be distroless or whether we need a slightly bigger one for debug comfort in non-prod. Quick reference reading while we do this: the Docker build cache guide for layer design, the Docker Buildx multi-platform docs for cache distribution, and the OCI Distribution Spec for why registry caches work the way they do. We’ll keep the promise simple: smaller images, reliable caches, safer defaults—and yes, fewer “works on my machine” stickers on our laptops.
