✦ For everyone, free.

Practical knowledge for real and everyday life

Home

5.2.2 BuildKit Cache

A focused guide to BuildKit Cache, connecting core concepts with practical Docker and container operations.

BuildKit cache refers collectively to the various caching mechanisms BuildKit provides — the standard layer cache, cache mounts for persistent package downloads, and exportable cache for sharing across machines — that together determine how much of a given build can avoid redundant, repeated work.

The Standard Layer Cache

At its most basic, BuildKit's layer cache works similarly to the legacy builder's: if a step's inputs match a previous build's inputs exactly, the previous result is reused rather than re-executed.

COPY requirements.txt .
RUN pip install -r requirements.txt
docker build -t myapp .
docker build -t myapp .

The second build reuses both layers entirely, assuming nothing changed between the two invocations.

Cache Mounts for Finer-Grained Persistence

Beyond the standard layer cache, cache mounts let specific directories — typically package manager download caches — persist independently of whether the layer using them is itself rebuilt.

RUN --mount=type=cache,target=/root/.cache/pip pip install -r requirements.txt
Exportable Cache for Cross-Machine Reuse

BuildKit's cache can also be exported to and imported from external storage, enabling cache reuse across entirely separate machines, which the legacy builder's purely local cache had no equivalent for.

docker buildx build --cache-to type=registry,ref=myregistry/cache --cache-from type=registry,ref=myregistry/cache -t myapp .
Choosing Which Caching Mechanisms to Use

Different projects benefit from different combinations of these mechanisms — a simple local project may need nothing beyond the standard layer cache, while a project built across many ephemeral CI runners benefits significantly from exportable cache.

docker buildx build --cache-to type=local,dest=/tmp/buildcache -t myapp .
Why Understanding BuildKit's Caching Options Matters

Knowing which caching mechanism addresses which specific scenario — local iterative development, package download persistence, or cross-machine CI reuse — allows a project to deliberately choose the right combination rather than relying solely on the most basic layer cache and missing out on meaningful additional speed improvements available elsewhere.

Content in this section