Skip to content

fix(monitoring): name untagged images in Docker Disk Usage - #115

Merged
agentHits merged 1 commit into
AgentHits-Devfrom
fix/untagged-image-names
Oct 28, 2026
Merged

agentHits merged 1 commit into
AgentHits-Devfrom
fix/untagged-image-names

Conversation

@agentHits

Copy link
Copy Markdown
Collaborator

What

Docker Disk Usage on the Monitoring page no longer shows untagged images as <none>:<none>. Each one gets the name it really has, plus a subtitle that says why Docker keeps no tag for it.

Case Before After
An image from an earlier deploy: its tag moved to a newer build, and an exited swarm task still holds it <none>:<none> · Dangling local image ghcr.io/agenthits/dokploy:agenthits-dev · Previous version: the tag now points to another image
A compose image pulled by digest (redis:8-alpine@sha256:…) <none>:<none> · Dangling local image · Used by: no containers reported redis:8-alpine · Pulled by digest, no local tag · Used by: the running containers
An old pull that no container uses <none>:<none> registry/app@sha256:<12 chars> · Dangling local image

Why

Docker drops an image's tag once the tag moves to another image, and it never stores a tag for an image pulled by digest. The image's real name is still in the reference its containers were created from (Config.Image) and in RepoDigests. The page used only the REPOSITORY/TAG columns of docker system df -v.

How

  • The name comes from the container references, running containers first. When no container uses the image, it comes from RepoDigests.
  • Containers are matched to images by image id from docker container inspect. docker ps has no image id, and it shows a bare id once the tag has moved, so digest-pinned containers used to be missed.
  • Used by marks containers that are not running, e.g. panel.1.abc (exited). That is what keeps an old image on disk, and why docker image prune leaves it there.
  • Remote servers are unchanged: they still get only the summary.

Checks

  • New unit test for the three cases. The existing test was updated to the new container shape.
  • Full Vitest suite: 4303 passed, 5 skipped. tsc --noEmit for packages/server and apps/dokploy, Biome on the changed files: clean.
  • The new code ran on real docker system df -v, image inspect and container inspect output from a production host. All 28 untagged images got a name. For all 46 images, the Used by count matched the CONTAINERS column of docker system df -v.

🤖 Generated with Claude Code

Docker Disk Usage listed many images as "<none>:<none>" with the
subtitle "Dangling local image", including images that running
containers use. Docker keeps no tag for an image in two common cases:

- the tag moved to a newer pull or build (a redeploy of an application
  or of the panel itself), while an exited swarm task from the previous
  deploy still holds the old image;
- the image was pulled by digest, as compose does for "name:tag@sha256:"
  references, so no tag is stored locally at all.

The name is now taken from the reference the image's containers were
created from (running containers first), and from RepoDigests when no
container uses the image. A digest-only name keeps a short digest, so
"repo@sha256:<12 chars>". The subtitle says which case it is: "Previous
version: the tag now points to another image", "Pulled by digest, no
local tag", or "Dangling local image" when nothing uses it. Source lists
the references.

Containers are now matched to images by image id from docker container
inspect. docker ps gives no image id and shows a bare id once the tag
has moved, so digest-pinned containers were reported as "no containers
reported" before. Used by also marks containers that are not running,
e.g. "panel.1.abc (exited)", which shows why an old image is kept.

Checked against a real host's data: all 28 untagged images got their
names, and Used by matched the CONTAINERS column of docker system df -v.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@agentHits
agentHits merged commit 71f7426 into AgentHits-Dev Oct 28, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant