🚨 Docker Error Guide: 'No such image' — Fix Missing Image References and Tags

Overview

Docker cannot find a local image matching the name and tag you referenced:

Error response from daemon: No such image: myapp:1.4.2

Commands like docker run, docker tag, and docker save resolve their argument against the local image store. If no image with that repository and tag exists locally — because it was never pulled, never built, or built with a different tag — Docker returns No such image.

Symptoms

• docker run myapp:1.4.2 fails with No such image.
• docker tag or docker save on an image fails the same way.
• docker images does not list the repository/tag you expected.
• The image exists in a registry but not on this host.

Common Root Causes

• Image never pulled — referencing a registry image that has not been fetched locally (for commands that do not auto-pull).
• Tag mismatch — the local image is myapp:1.4.1 or myapp:latest, not myapp:1.4.2.
• Built with a different tag — the docker build -t value differs from what you run.
• Wrong registry prefix — myapp:1.4.2 versus registry.example.com/myapp:1.4.2.
• Image was pruned — docker image prune -a removed it.
• Referencing by a stale image ID — the ID changed after a rebuild.

Diagnostic Workflow

List local images and grep for the repository you expect:

docker images
docker images myapp

Check for the exact repository and tag combination:

docker image inspect myapp:1.4.2 >/dev/null 2>&1 && echo present || echo missing

If the image lives in a registry, pull it explicitly (some commands do not auto-pull):

docker pull registry.example.com/myapp:1.4.2

Confirm the tag your build actually produced, if you built locally:

docker build -t myapp:1.4.2 .
docker images myapp

Inspect the resolved reference and digest to be sure you have the intended image:

docker image inspect --format '{{.RepoTags}} {{.Id}}' myapp:1.4.2

Example Root Cause Analysis

A run command failed on a fresh CI runner:

Error response from daemon: No such image: registry.example.com/myapp:1.4.2

docker images on the runner showed no myapp image at all. The pipeline built the image in an earlier job on a different runner and never pushed it, so this runner had nothing locally. docker run does auto-pull for a missing image, but the private registry required credentials this job had not configured, so the pull silently was not attempted in the wrapper script that used docker create. The fix was to authenticate and pull explicitly before running:

docker login registry.example.com
docker pull registry.example.com/myapp:1.4.2
docker run registry.example.com/myapp:1.4.2

The takeaway: images are host-local. If a build happened elsewhere, the consuming host must pull it — and needs registry credentials to do so.

Prevention Best Practices

• Push build outputs to a registry and pull them by exact tag on every consuming host.
• Pin exact tags (myapp:1.4.2) in production instead of latest, which drifts and hides mismatches.
• Authenticate with docker login before pulling from private registries in CI.
• Keep docker build -t tags identical to the tags your run/deploy commands reference.
• Avoid aggressive docker image prune -a on hosts that expect images to persist between jobs.

Quick Command Reference

docker images myapp                       # list local images for a repo
docker image inspect myapp:1.4.2          # confirm exact repo:tag exists
docker pull registry.example.com/myapp:1.4.2
docker login registry.example.com         # auth for private registries
docker build -t myapp:1.4.2 .             # build with the intended tag

Conclusion

No such image means the referenced repository and tag are not in this host’s local image store. Confirm the exact tag with docker images, pull it from the registry if it was built elsewhere, and make sure build and run tags match. Pinned tags, explicit pulls, and registry auth in CI keep the error away. See more image and build fixes in the Docker stack guides.