Home / Alt manpages / docker-load(1)

  • docker-load(1)
  • User command
  • linux

Load a Docker Image from a Tar Archive Without Guesswork

You will finish with a Docker image imported from a tar archive, or from standard input, and a check that confirms what arrived in the local image store. The examples match Docker CE CLI 29.8.1, installed here as package docker-ce-cli 5:29.8.1-1~ubuntu.24.04~noble. The installed docker-load(1) page is dated September 2026 and documents docker load as an alias for docker image load.

Allow about ten minutes. You need a Docker daemon that is running, read access to the tar file, and enough local disk space for the unpacked image. Running the command normally is preferable. Use sudo only if your Docker setup requires it; adding elevated privilege does not repair a bad archive or a missing daemon.

1. Check the installed command

Confirm the CLI version and the exact options available on this host:

$ docker --version
Docker version 29.8.1, build 4a63305
$ docker load --help
Usage:  docker load [OPTIONS]

Load an image from a tar archive or STDIN

The relevant options are --input (or -i) for a tar file, --platform for one or more platform variants, and --quiet (or -q) to suppress load output. The command accepts no image name as a positional argument. The archive determines which repository names and tags are imported.

Checkpoint

If docker --version fails, stop here and fix access to the Docker CLI or daemon before investigating the archive.

2. Inspect the archive before importing it

Loading an archive changes the local Docker image store. It can add image layers and tags, and a large archive can consume substantial disk space. It does not delete an existing image merely because the same tag is present, but a tag may be moved to the imported image. Treat archives from outside your trusted supply chain as untrusted input.

First check the file itself without involving Docker. Replace the placeholder with an actual path:

$ ARCHIVE='/path/to/image.tar'
$ test -r "$ARCHIVE" && tar -tf "$ARCHIVE" | sed -n '1,12p'
manifest.json
repositories

A classic Docker image archive normally contains manifest.json, layer directories and configuration files. The listing is only a quick sanity check, not proof that the archive is safe or complete. Do not extract an untrusted archive into a working directory just to inspect it.

3. Load a named tar archive

Pass the archive with --input. This is an ordinary command for a user who can access the Docker daemon:

$ docker load --input "$ARCHIVE"
Loaded image: example/web:1.2.3

The output varies with the archive. It may mention more than one loaded image, or a digest rather than the example shown above. A successful return status matters more than the exact wording. If the archive contains no repository tag, Docker may report an image ID instead.

Checkpoint

Do not continue until the command returns to the shell with status zero. If it reports "open ... no such file", check the path. If it reports a daemon connection error, check the daemon separately:

$ docker info >/dev/null
$ printf 'docker info status: %s\n' "$?"
docker info status: 0

4. Verify the imported tag and image

Use the repository and tag printed by your own load output. Do not copy the example name unless that is genuinely the tag in your archive:

$ IMAGE='example/web:1.2.3'
$ docker image inspect "$IMAGE" --format '{{.Id}} {{.RepoTags}}'
sha256:REPLACE_WITH_LOCAL_ID [example/web:1.2.3]

The ID and tag are host-specific. The important result is that docker image inspect exits successfully and shows the expected repository tag. For a compact list of matching local images:

$ docker image ls 'example/web' --no-trunc
REPOSITORY   TAG     IMAGE ID       CREATED        SIZE
example/web  1.2.3   ...            ...            ...

Replace the repository filter with the real repository. An empty list usually means that the tag was guessed incorrectly, not necessarily that loading failed. Re-read the load output before running the import again.

5. Load from standard input

Use standard input when another command already produces the tar stream, or when the archive is held on a remote system. This form uses the same image-import operation and does not require a temporary file:

$ ssh backup-host 'cat /srv/images/example-web.tar' | docker load
Loaded image: example/web:1.2.3

Keep the pipeline simple. If the remote command fails, the local Docker client may receive a truncated stream and report an archive error. Check the SSH exit status and then repeat the verification step. For a local file, docker load < "$ARCHIVE" is equivalent to using standard input.

The --quiet option suppresses load output. It does not make the operation safer and it does not change what is imported. Use it in scripts only when you already record the source archive and check the command's exit status.

6. Select a platform from a multi-platform archive

When an archive contains multiple platform variants, select one with --platform. The documented format is os[/arch[/variant]]; multiple values are comma-separated:

$ docker load --input "$ARCHIVE" --platform linux/amd64
Loaded image: example/web:1.2.3

For an ARM variant, the form can include the variant component:

$ docker load --input "$ARCHIVE" --platform linux/arm64/v8
Loaded image: example/web:1.2.3

The platform must exist in the archive. A platform selector does not convert an image, compile a missing architecture or change the host kernel. If you need more than one variant, pass a comma-separated list such as linux/amd64,linux/arm64/v8, then verify the result against the tags and platform metadata your workflow expects.

7. Handle failures and undo a mistaken tag

Common failures have different causes:

  • A missing or unreadable file is a shell path or permission problem.
  • A daemon connection error is a Docker service, context or socket problem.
  • An invalid tar or missing manifest usually means the stream is not a Docker image archive, or it was truncated.
  • A requested platform that is absent cannot be loaded from that archive.

If an import added or moved a tag by mistake, stop any deployment that depends on that tag before changing it. Removing a tag is state-changing and may make an otherwise unreferenced image harder to find:

$ docker image rm 'example/web:1.2.3'
Untagged: example/web:1.2.3

This removes the tag, not necessarily the underlying image. Docker may refuse while containers or other tags still reference it. Do not add --force casually. If the old tag pointed to a known image, restore it only from a recorded digest or a trusted registry; do not guess at an image ID.

Done means

  • The archive was readable and its source was trusted.
  • docker load returned status zero.
  • The loaded repository and tag were taken from the command output, not guessed.
  • docker image inspect confirmed the expected local image.
  • A platform selector was used only when that platform exists in the archive.
  • You know which tag to remove or restore if the import changed local state unexpectedly.