19.1.2.1 Images Local Listing

Images local listing clarifies precisely what "local" actually means when running docker images: the result reflects only the specific daemon the current Docker context is pointed at, never queries any registry, and can produce a meaningfully different result depending on which context is active, a distinction worth understanding explicitly rather than assuming "local" simply means "this machine" universally.

Local means this specific daemon, not necessarily this machine

docker images queries whichever daemon the active Docker context currently points to, which is not always the same as the physical machine the command is typed on, particularly when using a remote context or Docker Desktop's own internal VM-based daemon:

docker context ls

NAME              DESCRIPTION
default *         Current DOCKER_HOST based configuration
remote-server     SSH connection to remote-server

docker context use remote-server
docker images

Switching context here changes which daemon's image list docker images actually reflects, which means the exact same command, typed identically, can return entirely different results depending purely on which context happens to be currently active, a detail easy to overlook and a common source of confusion when an expected image appears to be "missing" simply because a different context than intended is active.

docker images never queries a registry

This command exclusively reflects images already present on the queried daemon; it has no awareness of, and makes no request to, any remote registry at all, which means an image that exists in a registry but has never been pulled to this specific daemon simply will not appear in this listing, regardless of how recently or how many times it has been pushed elsewhere:

docker images my-api

REPOSITORY   TAG       IMAGE ID

An empty result here does not mean the image does not exist anywhere; it means specifically that this daemon has never pulled it, which is an important distinction when troubleshooting, since the actual fix in this scenario is pulling the image, not investigating why an existing, registry-hosted image somehow disappeared from local listing.

Comparing to docker search for registry-side querying

docker search, by contrast, queries a registry (by default, Docker Hub) directly, providing the registry-side equivalent of what docker images provides for local content:

docker search nginx

NAME                 DESCRIPTION                  STARS
nginx                Official build of Nginx       19000

These two commands serve genuinely complementary purposes and should not be confused: docker images answers "what do I already have locally," while docker search answers "what exists in a registry that I could pull," and neither command provides any information that overlaps meaningfully with the other's actual scope.

Verifying which daemon a listing actually reflects

When uncertain whether a docker images result reflects the intended daemon, confirming the active context and the daemon's own identifying information directly removes any ambiguity:

docker context show
docker info --format '{{.Name}}'

This kind of explicit confirmation is particularly worth doing on a machine that regularly switches between contexts, a local Docker Desktop instance and one or more remote, SSH-accessed daemons, for instance, where assuming "local" always means the same thing consistently can lead to confusing, misattributed troubleshooting.

Local listing across multiple daemon instances

For a workflow genuinely needing to compare image inventories across several distinct daemons, the comparison requires explicitly switching context (or specifying -H directly) and querying each daemon individually in turn, since no single docker images invocation aggregates results across more than one daemon simultaneously:

docker -H ssh://user@host1 images
docker -H ssh://user@host2 images

There is no built-in, single-command way to see a combined, multi-daemon inventory at once; each daemon's local image set is genuinely separate and queried independently.

Common mistakes

• Assuming docker images always reflects the physical machine the command is typed on, missing that the active context determines which daemon is actually being queried.
• Investigating why an image "disappeared" from local listing when it was actually never pulled to this specific daemon in the first place, having only ever existed in a registry or on a different daemon.
• Confusing docker images and docker search, expecting one to answer the question the other is actually designed to address.
• Not confirming the active context explicitly before troubleshooting an unexpected local listing result, especially on a machine that regularly switches between multiple daemon contexts.
• Expecting a single command to aggregate image inventory across multiple separate daemons, when each daemon's local listing must be queried individually and explicitly.

Images local listing reflects exactly one specific daemon's own content, determined by whichever Docker context is currently active, never extends to querying any registry directly, and understanding this scope explicitly, rather than assuming "local" universally means "this physical machine," resolves a surprising amount of confusion when an expected image seems unexpectedly absent from a listing.