Published ยท Updated
Why Docker cache export can outlast the build
A fast Docker build can still spend minutes exporting cache. Learn what BuildKit is moving, which cache mode fits the job, and what to measure before changing backends.
Cache export continues after Dockerfile execution.
BuildKit can finish executing Dockerfile instructions and still have work left to do. An external cache export serializes cache records and transfers reusable layers to the selected backend so a future builder can import them.
That cost is easiest to notice on an ephemeral CI runner. The local BuildKit store disappears with the machine, so the export is what makes the work available to the next run. A short build with a large cache graph can therefore spend more time exporting than executing.
mode=min and mode=max export different sets of layers.
Use mode=min for final-image layers
It exports cache for layers that contribute to the final image. The result is usually smaller and quicker to move, but intermediate stages may need to run again.
Use mode=max for intermediate stages too
It includes intermediate stages as well as layers used by the final image. That can improve repeat builds with multi-stage Dockerfiles, at the cost of a larger export.
Start with the smallest cache that preserves the expensive work your next build actually needs. More exported data is only useful when later builds can reuse it.
Separate execution, import, and export time.
- 1. Record a cold run. Keep the repository, Dockerfile, runner size, region, and image output fixed.
- 2. Record a warm run. Confirm which stages report cache hits instead of treating total workflow time as a cache measurement.
- 3. Time the export. A large upload may point to cache depth, compression, network throughput, or repeated publication from too many jobs.
- 4. Change one variable. Compare cache modes or backends with the same workload. Keep image push, tests, and unrelated setup outside the number where possible.
Reuse layers and caches inside Docker instructions.
The BoringCache Docker adapter uses a native BuildKit backend to share layers across CI and local builds. BuildKit decides which instructions can be skipped. Optional persistent cache mounts and native tool caching preserve dependency and compiler results when instructions rerun. Compare total build time, including cache transfers, using the linked Docker benchmarks.
Start with your repository
Run boringcache onboard once. BoringCache finds useful cache state, writes .boringcache.toml, and keeps the same cache names across local builds and CI.