Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A bare SHA in docker ps --format '{{.Image}}' is not proof that an image is unused. Christian Anderson, writing about his Proxmox homelab, saw SHA values instead of familiar image names and thought unclecode/crawl4ai looked orphaned. Checking the containers showed it was running, healthy, and serving traffic. Before removing an image, connect it to its containers and verify what those containers are doing.
Why docker ps can make a live image look unused
Anderson’s incident began with a summary command that printed bare image IDs rather than recognizable repository names. That made a live workload look like cleanup material: the image appeared “orphaned,” but a container using it was active. The exact formatting behavior is Anderson’s account; the Docker CLI version that produced it was not established.
The practical risk is not that docker rmi automatically stops a running container. It is that acting on an ambiguous summary without checking references can lead to a destructive cleanup decision affecting a live service. Treat the output as a clue, not an authoritative inventory.
Trace image IDs to containers before removing anything
Docker’s inspect reference describes docker inspect as providing detailed information about Docker-controlled objects, including a container’s configured image. First list running containers, then inspect their configured image values:
#1 Best Overall
docker ps --format '{{.ID}} {{.Image}} {{.Names}}'
docker inspect -f '{{.Name}} {{.Config.Image}}' $(docker ps -q)The first command helps you identify active containers; the second prints each running container’s name and configured image. To inspect one container directly, use its name or ID:
docker inspect -f '{{.Name}} {{.Config.Image}}' CONTAINERCompare the configured image with the ID or tag you intend to remove. If names and IDs are unclear, inspect the relevant image and container details rather than inferring that a SHA has no owner. A listening port or another check of service activity can corroborate that a workload is live, as it did in Anderson’s account, but it does not replace tracing the container-to-image reference.
Rank #2
Know what Docker image pruning removes
“Dangling” and “not referenced by a container” describe different cleanup scopes. Docker’s image-prune documentation says docker image prune removes dangling images by default. Adding -a broadens the scope to images not referenced by any container:
| Command | Documented scope | What to check first |
|---|---|---|
docker image prune |
Dangling images by default | Review the proposed cleanup and confirm whether dangling images are needed for your workflow. |
docker image prune -a |
Images not referenced by any container | Check stopped containers and images needed by planned or Compose-managed workloads before broad cleanup. |
Do not treat an estimated reclaimable amount as a dependency audit. Anderson reported that some non-running images on his host were still referenced by Compose files, and the cleanup returned much less storage than the summary figure suggested. Review what a command will affect and how you would restore any needed image before running broad pruning unattended.
Rank #3
“Orphaned” in Compose is a different question
Docker Compose uses “orphaned services” in relation to a project definition, not as a general verdict that an image is unused or its container is stopped. The Compose ps reference defines the option for including services not declared by the project. A service can be an orphan relative to the current Compose file while still having a container, and that label alone does not tell you whether an image is backing a live workload.
Declared configuration may not match the live container
In his homelab, Anderson found a Compose file specifying restart: unless-stopped while an older container still had restart=no. The container had not been recreated, so editing the project file had not changed the existing object. He also described environment and application-code changes that were absent from containers still running their previous configuration or image.
The broader operational lesson is to inspect the live container, not just the file you expect to define it. When configuration or code changes need to take effect, use the appropriate Compose update or recreation workflow for that project, then verify the resulting container’s settings and behavior. The correct command depends on how the service was deployed; a file edit by itself is not evidence that the running object changed.
A healthy status does not prove the service works
A running process or passing health check can establish that a process is up without proving that the application is delivering its intended function. Anderson described a tunnel container marked healthy that did not connect the expected tunnel, and a GPU workload that fell back to CPU in his particular hardware and software combination. As he put it: “Healthy means the process is up. It doesn’t mean it’s doing its job.”
Best Value
- Docker, Docker Swarm, Docker Compose, Programmer, Developer, Coding, Programming, Software Engineer, Code, DevOps, Deploy, Deployment, Kubernetes, Salt, Puppet, Chef, Terraform, Container, AWS, Azure, Cloud, Geek, Funny, Computer, Software, Tech, IT
- Integration, Scrum, Compile, Compilation, Science, Bug, Debug, Python, Linux, Java, Javascript, Scala, Dotnet, Kotlin
- Lightweight, Classic fit, Double-needle sleeve and bottom hem
Test the outcome that matters to the service: for example, whether the expected endpoint responds or the intended tunnel is connected. Health status is useful evidence, but it is not a substitute for a functional check.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What the storage figures do—and do not—show
Anderson’s figures describe one homelab, not a general Docker benchmark. He reported four guests 82% to 86% full, 6.67 GB shown as reclaimable by docker system df, and about 340 MB reclaimed in the cleanup (Christian Anderson, 2026). In his investigation, images and build cache mattered more than cold data.
He also reported removing 16 superseded tags listed at about 240 MB each but freeing only 60 MB, because builds shared image layers. In this cleanup, adding the listed per-tag sizes did not predict the actual storage freed; those figures should not be treated as a universal storage ratio or forecast.
Free tools Windows power users keep installed
One-click scans. No signup required.
Anderson’s host ran Docker inside unprivileged LXC guests on Proxmox, alongside a NAS appliance operating as a layer over Docker. He described growing guest disks online from existing thin-pool capacity. That is a detail of his setup, not a general storage prescription for other Docker hosts.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
