What is a dangling image and how to prune it

WHAT THIS TESTS It checks whether you understand why disk fills up with images over time and can clean it safely without nuking images you still need.

A GOOD ANSWER COVERS A dangling image has neither a repository nor a tag, displayed as <none>:<none>. The common cause is rebuilding: when you build an image and reuse a tag, the tag moves to the new image and the previously tagged image becomes untagged but still occupies disk. These accumulate across many builds. You find them with docker images -f dangling=true and remove them with docker image prune, which by default deletes only dangling images. To go further, docker image prune -a removes all images not referenced by any container, and docker system prune cleans images, stopped containers, networks and the build cache together.

COMMON WRONG ANSWERS Equating dangling images with all unused images. Running docker image prune -a without realizing it removes tagged but currently unused images. Forgetting that running containers protect their images from pruning. Confusing image prune with container prune.

LIKELY FOLLOW-UPS What is the difference between prune and prune -a? What does docker system prune cover, including build cache? How do you reclaim space from the BuildKit cache specifically?

ONE CONCRETE EXAMPLE After dozens of CI rebuilds, docker images shows many <none>:<none> entries eating gigabytes. docker images -f dangling=true lists them; docker image prune (answer y) deletes just those orphaned layers, reclaiming space while leaving your tagged images and running containers intact.