Docker prune reports 0 B reclaimed while a buildx builder's volume holds 73 MB of cache

Read the 73 MB with care. The test build added 30 MB ^[4], but the Local Volumes row shows 73.31 MB ^[5]. That leaves about 43 MB the build does not account for ^[20]. The post calls the whole figure build cache ^[6] and does not break it down. The same row lists a reclaimable figure of 114.7 kB, or 0% ^[5]. The 0 B from `docker builder prune` is therefore a correct report on the daemon's own builder, whose Build Cache row is empty ^[5][7].

The volume is easy to find once you know the name. The node is usually the builder name plus 0 ^[3], so the builder `ci` in the test would own `buildx_buildkit_ci0_state` ^[21]. The post lists four checks ^[10]. `docker volume ls --filter name=buildx_buildkit_` returns one volume per docker-container node. `docker system df -v | grep buildx_buildkit_` gives sizes. `docker buildx ls` shows which builder each node belongs to. `docker buildx du --builder <name>` lists that builder's cache record by record.

The failure case is a host that drifted. A CI host that once ran `docker buildx create --use` and was later switched back keeps growing in a volume that `docker builder prune` never touches ^[8]. The post's fix is `docker buildx prune --builder <name>`. Add `--keep-storage 10gb` to keep a working set, or set a GC policy in that builder's `buildkitd.toml` ^[11].

The same symptom has a second cause. In both of the post's cases, `docker system prune -af` reports 0B while `df -h` shows the disk filling ^[1]. Docker Desktop and fresh Engine 29 installs use the containerd image store ^[12]. When a daemon is switched to it, the classic overlay2 images and containers are not deleted ^[13]. Docker's docs, quoted in the post, say: "Your overlay2 data remains on disk but becomes hidden." ^[14] On a real machine, the post says, the hidden amount is whatever existed before the switch, often many gigabytes ^[22]. A third case, moby#47089, is an `overlay2/` directory far larger than images, containers and build cache combined ^[17].

These are one author's numbers from a disposable `docker:dind` container ^[1][19]. The post discloses that Claude helped draft it from the dockdu repository's measurement log, and it closes by describing dockdu, a CLI that has run these checks since 0.4.0 ^[19][18]. According to the post, dockdu deletes nothing, and its Docker client rejects every request except GET or HEAD calls to four read endpoints ^[18].

A 30 MB build on a throwaway daemon does not indicate scale for a real CI host. We'd expect the behavior to transfer to any host with a docker-container builder that is not the selected one. The sizes will not transfer. The volume naming is cited in the post to the buildx source ^[2].