Where Docker Stores Images, and Why You Cannot Just Delete Them

By Kaveh Alemi·Latchkey

On Linux, images live under /var/lib/docker. On macOS and Windows they live inside a virtual disk, which is why the file is enormous and why deleting images does not shrink it.

This question is usually asked by someone who has run out of disk and wants to go in and delete something by hand. The honest answer is that the directory exists, you can find it, and you should not touch it: the layout is content-addressed and manipulating it outside Docker corrupts the image store.

What you actually want is either the path, for moving the whole thing to a bigger disk, or the reason the disk image will not shrink.

The paths

Why the directory is not browsable in any useful way

Images are stored as content-addressed layers, so a directory under overlay2/ is named by a hash and shared between every image that contains that layer. There is no folder per image, deleting one directory can break several images at once, and the daemon keeps its own index that will not know you did it. Use docker image inspect and docker system df -v to find out what is large, and prune commands to remove it.

The Docker Desktop file that will not shrink

On macOS and Windows the virtual disk grows as you use it and does not automatically give the space back when you delete images, because freeing space inside the VM leaves a hole in the file rather than making it smaller. Pruning inside Docker is still the right first step, and then the disk image has to be compacted separately.

• Prune first, inside Docker: docker system prune -a --volumes and docker builder prune -a. Nothing else can help until the space is free inside the VM.
• Then compact from Docker Desktop, under Settings, Resources, Advanced. Recent versions reclaim automatically after a prune; older ones need the disk reset.
• The nuclear option is Settings, Troubleshoot, Reset to factory defaults, which deletes every image, container and volume and recreates the disk at its minimum size.

Moving the store to a different disk

# /etc/docker/daemon.json, Linux
{
  "data-root": "/mnt/bigdisk/docker"
}

sudo systemctl stop docker
sudo rsync -aP /var/lib/docker/ /mnt/bigdisk/docker/
sudo systemctl start docker

Applying this to your pipeline

• Measure before changing. Most CI optimisation targets the wrong step because the slow one is assumed rather than timed.
• Cache what is expensive to produce and cheap to validate, and key the cache to the exact tool version.
• Fail fast: run the cheapest checks that can reject a change first, so an expensive job never starts on code that cannot pass.
• Prefer determinism over speed when they conflict. A fast pipeline nobody trusts gets re-run, which is slower than a slow one that is believed.

Frequently asked questions

Related guides

References

• Docker daemon configuration (verified 2026-08-31)
• docker system df reference (verified 2026-08-31)
• Docker documentation
• Docker build cache
• GitHub Actions documentation