Skip to content
Latchkey

Kaniko "--cache ... failed to retrieve" layer cache error in CI

With --cache=true, Kaniko stores and reads intermediate layers in a cache repository (--cache-repo). If that repo is unset, empty, or not authorized, Kaniko cannot retrieve cached layers and rebuilds every stage from scratch.

What this error means

Kaniko logs "No cached layer found" or "failed to retrieve layer" and rebuilds all stages, making cached builds no faster than cold ones.

kaniko
WARN[0002] Error while retrieving image from cache: registry.example.com/cache:abc123
GET https://registry.example.com/v2/cache/manifests/abc123: MANIFEST_UNKNOWN

Common causes

The cache repository has no layers yet or is unreachable

A MANIFEST_UNKNOWN on the cache repo means the layer was never pushed or the repo does not exist, so Kaniko falls back to a full rebuild.

--cache-repo is unset or not writable

Without a valid --cache-repo the credentials allow read/write to, Kaniko cannot persist or fetch cached layers.

How to fix it

Enable caching with an explicit cache repo

  1. Create a dedicated cache repository in your registry.
  2. Pass --cache=true and --cache-repo pointing at it.
  3. Ensure the config.json credentials can push to that cache repo.
Terminal
/kaniko/executor \
  --cache=true \
  --cache-repo registry.example.com/app/cache \
  --destination registry.example.com/app:latest

Verify the cache repo is writable

The first build populates the cache; confirm the same credentials that push the image can push to the cache repo, or later reads will miss.

How to prevent it

  • Use a dedicated --cache-repo with the same credentials as the push.
  • Expect the first run to be a cold build that seeds the cache.
  • Order Dockerfile layers so cacheable steps come before frequently-changed ones.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →