Most slow Docker builds are cache invalidation, not compute
Pipeline time for the typical service was cut roughly in half, and runtime images shrank substantially after build tooling was removed — which also reduced pull time and the vulnerability surface repo…
Overview
Slow container builds are almost always a layer ordering problem. A COPY of the full source tree before dependency installation invalidates the dependency layer on every commit, and no amount of faster build hardware fixes that.
Challenge
The CI pipeline had grown past twenty minutes per service and developers were batching changes to avoid waiting. Dockerfiles copied the entire repository before installing dependencies, had no .dockerignore so build context included the git history and node_modules, ran single-stage builds that shipped compilers and build tooling into the runtime image, and pinned nothing, so builds were not reproducible.
Environment
Dozens of containerized services built in CI and deployed to Kubernetes, with images pulled across regions.
Approach
AceMQ restructured the Dockerfiles around cache stability — dependency manifests copied and installed before source, multi-stage builds separating build tooling from runtime — and enabled a shared registry-backed build cache so CI agents benefit from each other's work rather than starting cold.
Solution
- 1Reordered layers so dependency installation precedes source copy and survives ordinary commits
- 2Added .dockerignore files to cut build context size dramatically
- 3Converted single-stage builds to multi-stage, keeping compilers and build tooling out of runtime images
- 4Enabled registry-backed BuildKit cache export and import so CI agents share cache
- 5Pinned base images by digest and pinned dependency versions for reproducible builds
- 6Established a per-service image size budget checked in CI
Outcome
Pipeline time for the typical service was cut roughly in half, and runtime images shrank substantially after build tooling was removed — which also reduced pull time and the vulnerability surface reported by scanners.
Technologies
Related Use Cases
Docker Container Security Hardening Assessment
Assessing and hardening container images and runtime configuration — non-root execution, read-only filesystems, and secrets that had been baked into layers.
Docker Disk Exhaustion and Build Cache Support
Stopping recurring build agent and node outages caused by unpruned Docker build cache, dangling images, and orphaned volumes filling the filesystem.
Need Docker Architecture Guidance?
AceMQ's senior Docker engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.