Docker eats disk quietly until a build fails with no space left on device, and docker system prune is the fix that will not touch data you still need. This reclaims disk space while keeping running workloads and named data volumes intact. The examples match Docker 29.8.1, installed here from the Docker Community CLI package. Allow about 10 minutes for inspection and a few more if the host has a large image cache.
You need a shell on the Docker host and permission to talk to its daemon. A user in Docker's configured group can run the commands normally. If Docker reports a permission error, repeat the read-only checks and the eventual prune with sudo, provided your administrator policy allows it. Do not put sudo in front automatically: membership of the Docker group already grants highly privileged control of the host.
Warning: Pruning deletes Docker objects. A deleted image can be pulled or rebuilt again, but a deleted stopped container is not recoverable as a container, and a deleted anonymous volume may contain the only copy of data. Stop here if you cannot identify the objects your services need.
Start with identity and usage. These commands do not remove anything.
docker --version
docker system df
docker ps --all
docker volume lsOn this host, the version check reports Docker version 29.8.1. The disk report shows Docker's space categories, while docker ps --all includes stopped containers that a normal prune can remove. The volume list is your prompt to check whether an apparently unused volume is an intentional backup, database store or development fixture.
Checkpoint: Write down any stopped container, image or volume that must remain. A volume being absent from a running container is not proof that its contents are disposable.
The plain command removes stopped containers, networks unused by containers, dangling images and unused build cache. It does not remove volumes by default. That default is deliberate, because an unreferenced volume may still hold useful data.
Run the command without --force when you want Docker to show its confirmation warning first:
docker system pruneReview the warning and answer y only when the scope is acceptable. Answer n or press Enter to leave the host unchanged. The successful run ends with a line such as Total reclaimed space: 1.84kB, although the amount and the deleted-object lists depend on the host.
This is not a preview. Docker's confirmation prompt tells you the object classes that the selected command can remove, not an exact complete list of object IDs. Treat the prompt as a final safety boundary, not as a substitute for the inspection in step 1.
Use filters when a time or label boundary is safer than a broad cleanup. The supported filter keys are until and label. For example, this keeps recent objects and only considers containers, images and networks created before the daemon's current time minus 30 days:
docker system prune --filter "until=720h"The until value is evaluated by the Docker daemon. Duration strings such as 720h, Unix timestamps and supported date formats are accepted. Use a duration when you want the rule to travel with a maintenance script; use an explicit timestamp when you need an auditable cut-off.
Labels are safer when your team marks disposable resources consistently. This example limits removal to objects carrying the exact label:
docker system prune --filter "label=cleanup=temporary"Different filter keys are combined with AND logic. Repeating the same key combines its values with OR logic. Test your label convention against docker ps --all --filter "label=cleanup=temporary" and the relevant image or volume listing before making the prune non-interactive.
Add --all only if you accept removal of every unused image, not just dangling image layers. An image that is not currently attached to a container may still be the fast rollback path for a deployment.
docker system prune --allKeep named data out of this operation unless you have a documented reason. The local command exposes --volumes for pruning anonymous volumes. Docker's current reference also describes this as the point where unused anonymous volumes become eligible, so do not assume that a named volume is disposable merely because no container is running.
docker system prune --volumesCombining --all and --volumes is the broadest form of this command. It can remove stopped containers, unused networks, unused images, unused build cache and eligible anonymous volumes. Use it only after checking volume ownership and confirming that rebuilds and backups are available.
After an accepted prune, check space and the surviving workloads again:
docker system df
docker ps
docker volume lsLook for the expected reduction in reclaimable space, healthy running containers and the volumes you deliberately retained. If a service needs a removed image, pull the known tag or rebuild it from its source. If a stopped container was removed, recreate it from its Compose file, deployment manifest or recorded docker run command. Docker does not provide an undo command for a prune, so recovery depends on those external definitions and backups.
For scheduled maintenance, prefer an explicit filter and leave the confirmation prompt in place until a supervised run has produced the expected result. Only then use --force, and keep the exact command in the maintenance record:
docker system prune --force --filter "until=720h"--force changes interaction, not scope. It suppresses the prompt; it does not make deletion safer, narrower or reversible.
docker system df shows the intended space change.docker ps and respond to their normal health checks.--all, --volumes or --force only with an explicit reason.