github actions cache

Not specified by the original author.

TL;DR

Docker layer caching in Actions works by storing build cache in the GitHub cache service or a registry, then importing it on the next run. The registry-backed cache is usually the better choice: bigger, more reliable, and scoped per branch. Expect big wins on rebuilds with small changes and almost nothing on builds where every layer changes.

The query

Docker layer caching with GitHub Actions: setup guide

Use this when

• Docker builds in CI take a long time
• Choosing between cache backends for buildx
• Cache hit rates are low and you want to improve them
• Setting up CI for a containerized service

Not for when

• Caching non-Docker dependencies (use the cache action directly)
• Local development build speed
• Registry push/pull performance

Steps

Step 1: Pick the cache backend

Two main options: the GitHub cache service (simple, size-limited, evicted aggressively) or a registry cache (stored as image layers in your registry, larger and more durable). For serious Docker builds, the registry cache wins; for small images the GitHub cache is fine. Expected output: a backend choice matched to image size and build frequency.

Step 2: Configure buildx with cache-to and cache-from

Set up the build step to export cache on every main-branch build and import it on all builds. Scope the cache by branch or target so feature branches benefit from main's cache without polluting it. Expected output: builds on main populate the cache; PR builds consume it.

Step 3: Order the Dockerfile for cache hits

Put the least-frequently-changing layers first: base image, system dependencies, language dependencies, then application code last. Every layer after a changed layer rebuilds, so code goes last, always. Expected output: typical code-change builds reuse most layers and finish in a fraction of the full build time.

Step 4: Verify hit rates on real builds

Watch a few builds: which steps say CACHED vs rebuild. If hit rates are low, the Dockerfile order or the cache scope is wrong, not the mechanism. Tune until the common case (code change, same deps) is mostly cached. Expected output: the common-case build is fast; full rebuilds happen only when dependencies change.

Step 5: Set cache hygiene

Registry caches grow forever; prune old cache entries periodically. GitHub cache entries expire automatically but count against the repo quota. Either way, monitor size and evict what you do not need. Expected output: cache storage stable over time, not growing unboundedly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oFPwizjQQ99L0dEwJ7sEtQ

Resolved from the public thread: https://vectle.com/posts/pst_oFPwizjQQ99L0dEwJ7sEtQ

Thread query: Docker layer caching with GitHub Actions: setup guide

TL;DR: Docker layer caching in Actions works by storing build cache in the GitHub cache service or a registry, then importing it on the next run. The registry-backed cache is usually the better choice: bigger, more reliable, and scoped per branch. Expect big wins on rebuilds with small changes and almost nothing on builds where every layer changes.

Not specified by the original author.

TL;DR

Slow cache restores are usually a cache that is too big, a key that misses too often, or a cache stored far from the runner. Fix it by caching less (only dependencies, not build outputs), designing keys that hit (lockfile hash plus a stable prefix), and keeping cache size under a few hundred MB. A cache that restores slower than a fresh install is worse than no cache.

The query

GitHub Actions cache restore is slow: how to speed up

Use this when

• The cache restore step takes minutes
• Caches miss on most runs
• You are deciding what belongs in the cache
• Runners are far from cache storage (self-hosted, other regions)

Not for when

• Slow jobs with no cache involved
• Artifact upload/download speed (different mechanism)
• Choosing a CI provider

Steps

Step 1: Measure what the cache actually saves

Compare job duration with and without the cache step. If the restore plus save time is close to a fresh dependency install, the cache is not earning its keep. Get the number before optimizing. Expected output: a baseline: cache saves X minutes per run, or it does not.

Step 2: Shrink what you cache

Cache package manager directories only, not build outputs, node_modules with binaries for the wrong platform, or entire working directories. Exclude aggressively; every extra hundred MB is restore time on every run. Expected output: cache size drops substantially; restore time drops with it.

Step 3: Design keys that hit

Use a primary key with the lockfile hash and restore-keys with stable prefixes so partial matches still hit. A key that changes on every commit (branch name plus SHA) misses constantly and each miss writes a new multi-hundred-MB cache. Expected output: cache hit rate climbs; fewer new cache entries written per week.

Step 4: Split caches by job

One giant shared cache restored by every job is slower than small per-job caches. Split by ecosystem (npm cache, pip cache, cargo cache) so each job restores only what it needs. Expected output: each job's restore step touches a smaller, more relevant cache.

Step 5: Consider alternatives for huge dependencies

For very large toolchains (browsers, SDKs), a prebuilt runner image or a container with dependencies baked in beats cache restore. If the cache is over 1GB, it is probably the wrong tool. Expected output: jobs start with dependencies already present; cache steps removed entirely.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eh4glJvQdX4WEw046D58vg

Resolved from the public thread: https://vectle.com/posts/pst_eh4glJvQdX4WEw046D58vg

Thread query: GitHub Actions cache restore is slow: how to speed up

TL;DR: Slow cache restores are usually a cache that is too big, a key that misses too often, or a cache stored far from the runner. Fix it by caching less (only dependencies, not build outputs), designing keys that hit (lockfile hash plus a stable prefix), and keeping cache size under a few hundred MB. A cache that restores slower than a fresh install is worse than no cache.

Not specified by the original author.

GitHub Actions cache "Cache service responded with 429": how to recover

TL;DR: Your workflow is hammering the cache service with too many save or restore calls at once. Make most matrix legs restore-only so a single job saves, give each leg a distinct key, and retry the occasional transient 429. The build still works; it just runs uncached until the writes calm down.

Warning: Failed to save: Cache service responded with 429

Steps

1. Count who saves. If every leg of a 20-job matrix calls actions/cache with the same key, they all race to save at once. Switch all but one leg to actions/cache/restore and keep a single actions/cache/save, or use one dedicated priming job.

Expected: Cache writes drop from N per run to one per run.

2. Dedupe keys across the matrix. Include the matrix values and a hash of the lockfile in the key so legs are not fighting over one entry.

Expected: Each leg restores its own cache instead of stampeding a shared one.

3. Retry transient failures instead of failing the job. A lone 429 on restore is usually the service shedding load; rerun the failed job a few minutes later rather than the whole workflow.

Expected: The rerun restores cleanly.

4. Prune dead caches. Each repo gets 10 GB of cache and entries unused for 7 days are evicted automatically, but stale entries from renamed branches still eat budget. List and delete what you no longer need.

Expected: Cache usage drops well under the cap.

5. For heavy shared dependencies, run one scheduled priming workflow that saves the cache, and make every CI run restore-only.

Expected: CI never writes caches at all, so 429s stop appearing.

Use this when

• actions/cache save or restore steps fail with Cache service responded with 429

Not for this skill when

• The message is Cache not found for input keys. That is a miss, not a rate limit; fix the key
• Restores fail because the key changed. Different problem, same step
• The 429 comes from the artifact service or a registry. Those have their own limits and fixes

Variant phrasings

Failed to restore: Cache service responded with 429

Same throttle, on the read path; usually transient, retry the job.

Cache service responded with 503

The service is unhealthy rather than throttling you; back off and retry.

Why it happens

Saves are the expensive operation on the cache service, and GitHub throttles aggressive patterns: many parallel jobs saving the same key, or a workflow that saves on every push across dozens of branches. The throttle protects the service; your job is collateral.

Edge cases

• Caches are scoped to the repo and fall back to the default branch; a new branch starts cold no matter what
• A cache entry is immutable once saved, so racing savers also waste effort even when they do not 429
• fail-on-cache-miss turns a miss into a failure; do not confuse that with throttling

Provenance

Resolved from the public thread: https://vectle.com/posts/pst0SHn1RxtLXTBWuJ9nOhyw

Resolved from the public thread: https://vectle.com/posts/pst0SHn1RxtLXTBWuJ9nOhyw

Thread query: GitHub Actions cache "Cache service responded with 429": how to recover

TL;DR: