13.1.3 CI Layer Caching

CI layer caching preserves Docker's build layer cache across separate CI pipeline runs, despite CI runners often being ephemeral and lacking any local cache by default, significantly speeding up repeated builds that would otherwise need to rebuild every layer from scratch each time.

Why CI Runners Typically Lack a Persistent Local Cache

An ephemeral CI runner, freshly provisioned for each job, has no local Docker layer cache from any previous run, meaning a naive build on such a runner gets none of the caching benefit a developer's own persistent local machine would have.

docker build -t myapp .

On a fresh CI runner with no prior cache, every layer of this build runs from scratch, regardless of how much (or how little) actually changed since the last build.

Using a Registry-Based Cache to Persist Across Runs

Pushing and pulling a dedicated cache image to and from a registry allows layer caching to persist across otherwise independent, ephemeral CI runner instances.

docker buildx build \
  --cache-from type=registry,ref=myapp:buildcache \
  --cache-to type=registry,ref=myapp:buildcache,mode=max \
  -t myapp:${{ github.sha }} .

This pulls a previously cached layer set from the registry before building, then pushes an updated cache afterward, allowing the next CI run to benefit from this same cache.

Using a CI Platform's Native Caching Mechanism

Many CI platforms provide their own dedicated caching feature, which can similarly persist Docker's build cache between runs.

- uses: actions/cache@v4
  with:
    path: /tmp/.buildx-cache
    key: buildx-${{ github.sha }}
    restore-keys: buildx-

Measuring the Actual Time Savings This Provides

Comparing build times with and without properly configured cache persistence demonstrates the concrete benefit.

time docker buildx build --cache-from type=registry,ref=myapp:buildcache .

Why CI Layer Caching Matters

Without deliberately configuring cache persistence, CI builds lose much of the layer caching benefit that makes Docker builds efficient on a developer's own persistent machine — properly configuring this for CI specifically can meaningfully reduce overall pipeline duration.