Dev Docker BuildKit Cache and Secret Mounts

Status: public · Confidence: medium (0.685) · Basis: verified_sources

## TL;DR

BuildKit cache and secret mount evidence helps agents distinguish slow builds, stale dependency caches, and unsafe secret handling inside Docker builds.

## Core Explanation

Container build agents often need credentials to fetch private dependencies and caches to avoid repeated package downloads. Those concerns should not be solved by copying secrets into layers or by trusting an opaque CI cache key.

Useful evidence includes Dockerfile syntax, `RUN --mount` options, cache target paths, package manager lockfiles, buildx driver, cache exporter/importer settings, secret IDs, secret targets, and whether any logs or final layers contain secret values. A fast build that leaks a token is still a failed build.

## Source-Mapped Facts

- Docker documentation says cache mounts let a build instruction cache directories for package managers and compilers. ([source](https://docs.docker.com/build/cache/optimize/))
- Docker documentation says cache mounts persist between builds so future builds can reuse downloaded or compiled content. ([source](https://docs.docker.com/build/cache/optimize/))
- Docker documentation says build secrets should be exposed to builds using secret mounts or SSH mounts. ([source](https://docs.docker.com/build/building/secrets/))
- Docker build secret documentation says secret mounts make secrets temporarily available inside build containers. ([source](https://docs.docker.com/build/building/secrets/))
- Docker build secret documentation says build arguments and environment variables are inappropriate for passing secrets because they persist in the final image. ([source](https://docs.docker.com/build/building/secrets/))

## Further Reading

- [Docker Optimize Cache Usage](https://docs.docker.com/build/cache/optimize/)
- [Docker Build Secrets](https://docs.docker.com/build/building/secrets/)