Docker BuildKit Cache Export/Import: Missing Automatic Invalidation

Goal

Investigate how Docker BuildKit’s cache export/import mechanism can retain stale layers when Dockerfile changes are not reflected in the cache key. The aim is to understand the constraints that allow stale cache results to persist, the lack of automatic invalidation, and the permission boundaries that expose exported cache data to any Docker group member.

Constraints & Uncertainty

Docker BuildKit computes cache keys from Dockerfile instructions and build context. However, exported cache data is not purged or invalidated automatically when a Dockerfile is modified. There is no built‑in TTL or expiration policy for exported cache, so cache size can grow indefinitely unless manually cleaned. Exported cache resides in the Docker daemon’s storage (e.g., /var/lib/docker/overlay2), giving all Docker‑group users read access to potentially sensitive build artifacts.

Open Questions

• What mechanisms can be introduced to automatically invalidate or purge cache entries that are no longer valid after a Dockerfile change, without requiring manual pruning?
• How can a TTL or size‑based expiration policy be declaratively configured for exported caches to prevent uncontrolled growth?
• What permission controls can be applied to the exported cache storage to restrict access to only authorized users or processes?