Pull-Through Cache

What Is a Pull-Through Cache?

A pull-through cache is a registry that sits between a client and an upstream source. On the first request for an image it fetches that image from upstream, stores a copy, and serves it. Every later request for the same image is served locally without reaching upstream again.

The obvious benefits are bandwidth, latency and resilience against upstream rate limits or outages. The more significant one is control. Because the cache is where an image reference is resolved, it determines what a given reference actually returns.

That property is why pull-through caches appear in almost every container security rollout. Repoint the cache at a different upstream source and the next pull returns a different artifact, with no change to any Dockerfile, build script or deployment manifest.

How a Pull-Through Cache Differs From a Mirror or a Proxy

The three are frequently confused, and choosing the wrong one creates avoidable operational work. The distinctions:

A pull-through cache populates lazily, on demand, and retains what was actually requested.
A mirror copies content on a schedule whether or not anyone needs it — predictable and complete, at higher storage cost.
A proxy forwards requests without retaining anything, so there is no bandwidth saving and no offline resilience.
A registry replica synchronises between registries in both directions, which is a different problem again.

Every major registry implements caching in some form. Amazon ECR calls them pull-through cache rules; Artifactory, Harbor, Nexus and Red Hat Quay offer equivalents under their own names. Echo states that its images are mirrored to Azure, Google Cloud, JFrog, Docker, GitHub, Nexus, Harbor and Quay (echo.ai/product), which matters here only because the cache must be able to reach whichever source you point it at.

Why Pull-Through Caches Determine Whether a Rollout Succeeds

Container security rollouts rarely fail on product fit. They fail on adoption, because the team that owns the registry is not the team that owns the hundreds of repositories containing FROM lines.

A cache resolves that mismatch structurally rather than socially. What it changes:

No developer action is required, so adoption does not compete with another team's roadmap.
The change is reversible with one command, which materially lowers the risk of piloting.
Migration and enforcement become separable, so you can move the default before policing it.
The registry becomes a single point of observation for what is actually pulled across the estate.

How to Operate a Pull-Through Cache in Production Environments

A cache is infrastructure and has its own failure modes. What to plan for before it carries production traffic:

Rotate upstream credentials deliberately. Expired upstream auth is the most common day-two failure, and it presents as intermittent pull errors.
Set lifecycle policies early. Lazy population is not bounded population; storage grows with every distinct image anyone tries.
Expect cold-start behaviour. During a large deployment an empty cache behaves like no cache, including against upstream rate limits.
Do not rely on it in air-gapped environments. A cache miss needs somewhere to go; disconnected networks need a seeded mirror instead.
Pair it with admission control. A cache changes the default source but enforces nothing, and developers can still reference upstream registries directly.

How Hardened Container Images Reach Teams Through a Cache

For an organisation adopting hardened images, the cache is usually the delivery mechanism rather than an optimisation.

The sequence that works is inventory first, then stand up the cache against existing upstream sources so nothing changes behaviourally, then pilot one service against the hardened source, then repoint the cache so new pulls resolve to hardened artifacts, and only then enforce with admission control.

Enforcing earlier converts a migration into an outage and spends the organisational goodwill the rollout depends on. The enforcement layer itself is covered in how to block unapproved container images in Kubernetes.

FAQs

Does a pull-through cache change anything for developers?

In normal operation, nothing. Image references, build commands and manifests stay exactly as they are, and the only observable difference is that the first pull of an uncached image is marginally slower while the cache populates. That invisibility is the point — it is what makes adoption feasible across teams who did not request the change.

What is the difference between a pull-through cache and a mirror?

A mirror copies content on a schedule regardless of demand, giving predictable completeness at higher storage cost. A pull-through cache populates lazily, fetching and retaining only images someone actually requested. For adoption work the cache usually fits better because it reflects real usage; for air-gapped environments a seeded mirror is the only workable option.

Can a pull-through cache work in an air-gapped environment?

Not on its own. A cache assumes it can reach upstream when it misses, which a disconnected network cannot do. The usual pattern is a seeded internal mirror populated through a controlled transfer process, with the same admission-control enforcement layered on top. The rollout order is unchanged; only the population mechanism differs.

Does a cache improve security by itself?

No. It changes which source images come from by default, which is a precondition for improving security rather than an improvement in itself. Developers can still bypass it by referencing an upstream registry directly. Admission control is what turns the new default into a requirement, and it belongs last in the sequence.

How much storage should we allocate?

Enough for the distinct images your estate actually pulls, which is typically far fewer than the number of repositories suggests. Measure before provisioning by inventorying current pulls. Then set lifecycle policies to evict images unused beyond a chosen window, because without them the cache grows with every one-off experiment anyone runs.