In this article
Inspect Docker's disk usage before pruning, and treat persistent volumes as data rather than disposable cache. Start with read-only inventory, choose a targeted cleanup and verify the applications you still need afterward.
The commands below follow Docker's documentation. They are examples for a developer workstation, not commands we have run against your environment.
Measure what occupies space#
Begin with:
docker system df -v
docker ps -a
docker volume lsThe first command reports Docker usage; the others help identify containers and volumes. Classify the large objects as images, build cache, container files or persistent data.
Do not assume every object marked unused is worthless. “Not currently referenced” is a technical condition, not a business decision about whether a database can be discarded.
Understand the object you are removing#
Docker's pruning guide describes separate cleanup commands and their scope. Read the help for the installed version before applying options from a copied command.
- Build cache can usually be regenerated, at the cost of slower future builds.
- Images may need downloading or rebuilding later.
- Stopped containers may contain changes you have not preserved elsewhere.
- Volumes can contain databases or other persistent application data.
Choose the smallest category that solves the problem instead of beginning with the broadest cleanup.
Inspect a volume before making a decision#
Use an exact known volume name for inspection:
docker volume inspect example-volumeReplace example-volume with a name from your inventory. Determine which application owns it and whether the application has a supported backup/export route.
Docker's volume documentation explains that volume data can persist independently of a container. Removing a stopped container is not proof that the corresponding data is no longer needed.
If you cannot identify a volume's owner, stop that part of cleanup and investigate. Do not use a guessed path to delete Docker's storage manually.
Target rebuildable cache when appropriate#
If build cache is the cause and you accept rebuilding it, inspect the command's options:
docker builder prune --helpThen use the documented cleanup that fits your case, reviewing the prompt before confirming. Avoid force flags while you are still learning what will be removed.
For containers or images, consider removing specific known disposable objects instead of pruning everything. Re-download time and offline availability may matter even when no irreplaceable data is involved.
Be careful with volume prune examples#
Docker's volume prune reference documents how options affect unused volumes. Read it for your installed version. Do not append a volume-removal flag to a broad system cleanup merely because an online guide promises more reclaimed space.
An unused database volume can still be the only copy of a project. Verify a recovery path before removing persistent data.
Confirm that cleanup helped#
Repeat the usage inventory, then start the development services you need. Check that expected data and configuration remain available.
If operating-system free space does not immediately match Docker's report, examine your Docker Desktop or platform's documented disk behavior rather than deleting random host files.
Prevent recurrence by understanding which process grows the largest category. Retaining every build and every disposable environment indefinitely may be an avoidable source of growth.
For Python project isolation, see the externally managed environment guide. For hosted resource costs, read AWS budget alert limitations.