Use Docker layer caching in GitHub Actions

A Docker build in CI with layer caching restores every unchanged layer from cache and rebuilds from the first changed instruction; a plain docker build on an ephemeral runner starts from zero every run.

ci.cache.docker-layersstatic · checkable from the repo
How StarSling works

AI agents open the PR

StarSling agents run this exact audit on your workflows, apply the fix, and open a reviewable PR automatically.

Do this

GitHub-hosted runners are ephemeral, so the local layer cache that makes docker build fast on a laptop is empty at the start of every CI run. Each run re-executes every Dockerfile instruction: base image pull, apt-get, dependency install, compile. Wiring BuildKit's GitHub Actions cache backend into docker/build-push-action persists layers between runs, so a change to application code reuses every layer above it and the build starts from the first instruction whose inputs changed.

.github/workflows/ci.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - name: Build image
        uses: docker/build-push-action@v6
        with:
          context: .
          tags: myapp:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

Avoid this

.github/workflows/ci.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .

How to detect it

  1. Search for plain builds: grep -rn 'docker build\|docker compose build' .github/workflows/ - a bare docker build on a hosted runner rebuilds every layer every run.

  2. Search for the action: grep -rn 'docker/build-push-action' .github/workflows/ and check each use for cache-from and cache-to; the action builds uncached when both are absent.

Tradeoffs and safety

  • The GitHub Actions cache backend shares the repository's 10 GB cache allowance with actions/cache; mode=max stores every layer (best hit rate, biggest footprint), mode=min stores final-stage layers. Watch eviction on repositories with many large caches.

  • Cache entries follow GitHub's branch scoping: a pull request restores from its own branch and the default branch. A first build on a new branch still pays the cold cost once.

  • Order Dockerfile instructions so what changes most often comes last; layer caching restores prefixes, and a COPY . . near the top invalidates everything below it on any file change.

  • Never write secrets into image layers to make them cacheable; use build secrets (--mount=type=secret), which stay out of layers and out of the cache.

Verify it worked

Hand this prompt to your coding agent (Claude Code, Cursor, and the like) to run this audit and open the fix as a reviewable PR.

Prompt for your coding agent
Audit this repository's Docker builds in CI and add layer caching where it is missing.

1. grep .github/workflows/ for docker build, docker compose build, and
   docker/build-push-action. For each build, note whether cache-from and cache-to are set.
2. For uncached builds, convert to docker/setup-buildx-action + docker/build-push-action
   with cache-from: type=gha and cache-to: type=gha,mode=max, preserving the existing
   context, tags, and push behavior exactly.
3. Read the Dockerfile: if a COPY of the whole source tree sits above dependency
   installation, propose reordering so dependency layers cache independently.
4. Read the Docker GitHub Actions cache docs linked on this page before editing.
5. Show the full diff and open a pull request; do not apply changes blindly. In the PR
   body, state how to verify: re-run the same commit and look for CACHED instructions.

Confirm the change landed

  1. Re-run the workflow on the same commit; the build log should show CACHED for unchanged instructions instead of executing them.

  2. Change one application source file and confirm the build reuses the base and dependency layers, re-executing from the first instruction that copies the changed file.

  3. Compare the build step's duration before and after on a warm cache; dependency-heavy images typically drop from minutes to well under one.

Go further

One fix, all of them, or forever.

You have the prompt for this one practice. Here is how much further you can take it, each step doing more for you than the last.

  1. Fix this one thing

    Copy the prompt above

    Hand OPT4 to your coding agent and fix it in your repo today.

  2. Fix everything, once

    Install the ci-speedup skill

    One prompt audits your whole repo against all 73 ci-speedup patterns (this one plus 72 more) and hands your agent every fix at once. Open source, MIT, runs locally.

  3. Keep it fixed, forever

    Install the StarSling GitHub App

    Connect GitHub and the fixes stay applied as your CI evolves, with agents that keep inspecting your workflows and opening optimization PRs you review.

Sources

1Docker: GitHub Actions cache (opens in new tab)

2Docker: cache backends (gha) (opens in new tab)

3docker/build-push-action (opens in new tab)

Last updated 2026-08-20