✦ For everyone, free.

Practical knowledge for real and everyday life

Home

5.2.2.1 BuildKit Local Cache

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

BuildKit local cache refers to cache that is stored and reused on the same machine where a build runs, the default and most common form of caching, requiring no extra configuration beyond what BuildKit already provides automatically for ordinary, repeated builds.

How Local Cache Works by Default

Without any special configuration, BuildKit automatically maintains a local cache of previously built layers, reused automatically whenever a subsequent build's inputs match.

docker build -t myapp .
docker build -t myapp .

The second build automatically benefits from local cache built up by the first, with no additional flags or setup required.

Where Local Cache Is Stored

The local cache lives within the Docker daemon's own storage on the host machine, meaning it persists across separate build invocations as long as they run against the same daemon.

docker system df

This command reports how much disk space the daemon's cache (along with images, containers, and volumes) is currently consuming.

The Limitation of Local Cache

Because local cache exists only on the specific machine where it was built, it provides no benefit to a different machine — a fresh CI runner, a different developer's laptop — building the exact same Dockerfile for the first time.

docker build -t myapp .

Run for the first time on a new machine, this build cannot benefit from any cache, regardless of how much cache exists on a different machine that has built this same image many times before.

When Local Cache Alone Is Sufficient

For local development on a single, persistent machine, local cache alone often provides the bulk of the practical caching benefit needed, without requiring the added complexity of exportable, shared cache.

docker build -t myapp .
Why Understanding Local Cache Matters

Recognizing that local cache is tied to a specific machine clarifies why a fresh CI runner or new developer machine experiences a slow, uncached first build even when the exact same Dockerfile has been built many times elsewhere — and helps identify when exportable cache becomes worth the added setup effort.