CI builds run on fresh, ephemeral runners, so every image build starts with an empty local build cache. How do you get cache hits anyway, and what are the tradeoffs of the approaches?

## The problem The build cache is builder-local state. Spin up a fresh container or VM per pipeline job and the builder starts blank, so a Dockerfile carefully ordered for cache reuse still rebuilds everything, every time. Fixing it means either (a) making the cache portable so it can be re-imported, or (b) making the builder durable so it never loses it. ## Exporting and importing cache BuildKit separates the *cache exporter* (`--cache-to`) from the *cache importer* (`--cache-from`). Both take a type and options. **`type=registry`** stores the cache as its own artifact in a container registry, typically a dedicated tag such as `repo/app:buildcache`. It is the most portable option: any runner with registry credentials can import it, including across CI systems and developer machines. Cost: registry storage and pull/push time. **`type=inline`** embeds cache metadata into the image you are already pushing, so there is no second artifact. It is the simplest to adopt and costs nothing extra to store — but it only describes layers present in the final image, so it behaves like `mode=min` and gives no hits for multi-stage builder work. **`type=gha`** (and equivalents for other providers) uses the CI system's own cache service. Usually the fastest inside that provider, subject to that provider's quotas and eviction — GitHub's cache, for instance, evicts under total-size pressure and scopes entries by branch with fallback to the default branch. **`type=local`** writes to a directory; useful with a self-hosted runner or paired with a cache-restore step. Watch for unbounded growth — without pruning it keeps accumulating. **`type=s3` / `type=azblob`** put the cache in object storage, which suits organisations that want one cache plane independent of the CI vendor. ## `mode=min` versus `mode=max` This is the single highest-leverage flag. `mode=min` (the default) exports only the layers that ended up in the final image. In a multi-stage build — the normal shape for compiled languages — the expensive work (dependency resolution, compilation) happens in a builder stage whose layers are *discarded* from the final image. With `min`, none of that is exported, so the next run re-runs the compile even though it 'has cache'. `mode=max` exports intermediate stage layers too. Hit rates jump; storage and export time grow. For most real pipelines `max` is correct, and the extra push cost is repaid on the first hit. ## Persistent builders — the other answer Instead of shipping the cache around, keep the builder alive: `docker buildx create` with a remote or Kubernetes driver, or self-hosted runners with a long-lived BuildKit daemon. The cache then stays local and hot, with no import/export traffic, and `RUN --mount=type=cache` directories (a Maven repository, an npm cache, the Go build cache) survive too — those never travel with registry cache and are otherwise lost on every ephemeral job. The tradeoff is that you now operate a stateful component: it needs disk, a GC policy (keep-storage limits in `buildkitd.toml` or a scheduled `buildx prune`), monitoring, and a security story, because a shared builder is shared state across builds. ## Scoping and correctness Cache scope decides hit rate. A common pattern is: export cache per branch, import that branch's cache first with a fallback to the main-branch cache, so a new feature branch starts warm from the last good main build. Too coarse a scope and unrelated builds evict each other; too fine and nothing is ever reused. There is also a trust boundary. Cache entries are build results. Letting untrusted pull-request builds *write* to a cache that trusted release builds *read* lets a hostile contributor influence a released artifact. The usual policy: forks and PRs may import cache, only trusted branches may export it. ## When caching is the wrong lever Measure before believing. Importing a multi-gigabyte cache over the network can be slower than rebuilding steps that only take a minute. Watch cache hit rate and end-to-end build time together, and be willing to conclude that a smaller build context, a narrower copy, better instruction ordering, or a prebuilt base image with the heavy toolchain baked in beats any cache configuration. A base image rebuilt nightly and pinned by digest is often the cheapest 'cache' there is. ## What a strong answer covers Name the mechanism (`--cache-to`/`--cache-from`), pick a backend with a reason, call out `mode=max` for multi-stage, mention scope with fallback, note that cache mounts need a persistent builder, and finish with the honest caveat that cache transfer is not free.