Docker "No such image" After load/import in CI - Fix Tag Loss Across Jobs

An image saved as a CI artifact and loaded in a later job is missing the tag you then reference. docker load restores whatever the tar held - if it was saved by ID or with a different tag, the expected name is absent.

What this error means

After docker load -i image.tar in a downstream job, a docker run/docker tag/docker push fails with No such image: <name>:<tag>. The image is present (by ID) but not under the name the later step uses.

Loaded image ID: sha256:9f2c...
Error response from daemon: No such image: myorg/api:1.4.2
# the tar was saved by image ID, so the tag was not restored

Common causes

The image was saved without its tag

docker save <image-id> (rather than docker save myorg/api:1.4.2) stores the image with no repo tag, so load brings it back untagged.

Tag mismatch between save and reference

The save used one tag and the downstream job references another, so the loaded image does not match the expected name.

Artifact loaded into the wrong job/runner

Local images are not shared across jobs; if the artifact was not downloaded and loaded in this job, the name simply is not present.

How to fix it

Save and load by the full tag

Persist the image with its repo:tag so the name survives the round-trip.

# upstream job:
docker save myorg/api:1.4.2 -o image.tar
# downstream job:
docker load -i image.tar
docker run --rm myorg/api:1.4.2

Re-tag the loaded image by its ID if untagged

If the tar was saved by ID, tag it after loading.

ID=$(docker load -i image.tar | sed -n 's/^Loaded image ID: //p')
docker tag "$ID" myorg/api:1.4.2

How to prevent it

• Always docker save by repo:tag, not by image ID.
• Use one canonical tag variable across save, load, and push.
• Download and load the artifact in the same job that references the image.

Related guides