Home / Alt manpages / docker-image-pull(1)

  • docker-image-pull(1)
  • User command
  • linux

Pull Docker Images Safely by Tag, Digest or Registry

You will download a Docker image, check the local result, and know when a tag, digest, registry host or platform is the right choice. The examples use Docker Community CLI 29.8.1 from the installed docker-ce-cli package, version 5:29.8.1-1~ubuntu.24.04~noble. Allow about ten minutes, plus the time needed to download the image. You need a working Docker Engine connection and a registry account when the image is private.

This command changes the local image store but does not start a container. Pulling an image may use substantial bandwidth and disk space. The normal command is unprivileged when your account can access the Docker socket; do not add sudo automatically. If your installation requires it, use the same privilege consistently for later image commands.

1. Check the installed command

Confirm the client and its pull syntax before copying an image reference from a ticket or deployment file:

$ docker version --format '{{.Client.Version}}'
29.8.1
$ docker image pull --help
Usage:  docker image pull [OPTIONS] NAME[:TAG|@DIGEST]

Download an image from a registry

The command has the shorter alias docker pull. The full docker image pull form makes it clear that this operation belongs to Docker's image management commands.

2. Pull one tagged image

Start with an explicit tag when the image publisher documents one. This example uses the Docker Official Images namespace:

$ docker image pull debian:bookworm
bookworm: Pulling from library/debian
Digest: sha256:IMAGE_DIGEST_PRINTED_BY_DOCKER
Status: Downloaded newer image for debian:bookworm
docker.io/library/debian:bookworm

The digest and layer identifiers are content-dependent, so your output will differ. On a second pull, Docker may report that the image is already up to date and reuse layers already in the local content-addressable store.

If you omit the tag, Docker uses :latest:

$ docker image pull debian
Using default tag: latest

That default is convenient for a quick test, but it is a moving name. For a repeatable build or service deployment, use the tag your project has selected, then consider pinning the resulting digest.

Checkpoint

A successful pull ends with a status line and the image reference. A failed command has not given you a usable local image, even if some layers appeared during the attempt.

3. Verify what is now local

List the repository and tag you requested:

$ docker image ls --filter reference=debian:bookworm
REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
debian       bookworm  4eacea30377a   ...           ...

The image ID, creation time and size vary with the image version and Docker's output formatting. The useful check is that the expected repository and tag are present. To inspect the exact reference and its metadata, use:

$ docker image inspect debian:bookworm

Inspect is read-only. Keep the image reference in the same form used by the command that consumes it; a tag can later point at a different image.

4. Pin an image by digest

A tag is a name that can move. A digest identifies one image manifest, so it is the better boundary for a deployment that must retrieve the same image again. Copy the digest printed by a trusted pull or release process, then use it after @:

$ docker image pull debian@sha256:REPLACE_WITH_A_64_HEX_DIGEST
docker.io/library/debian@sha256:REPLACE_WITH_A_64_HEX_DIGEST: Pulling from library/debian
Digest: sha256:REPLACE_WITH_A_64_HEX_DIGEST
Status: Image is up to date for debian@sha256:REPLACE_WITH_A_64_HEX_DIGEST

Do not treat the placeholder as a valid digest. Replace it with the complete value from your release record or the registry's trusted metadata. Pinning also pins old contents: security updates published under a later tag will not be selected until you deliberately change the digest.

5. Pull from a private or different registry

An image reference can include a registry host and optional port. It is not a URL, so do not add https://:

$ docker image pull registry.example.test:5000/team/app:2026.09

For a private registry, authenticate with docker login using the registry's documented credentials flow before pulling. A login token can grant access to private images, so never paste credentials into shell history, a script or a public issue. Docker normally contacts registries over HTTPS. An HTTP or otherwise insecure registry must be explicitly allowed by the Docker daemon configuration; changing that setting weakens transport security and needs an administrator.

If the registry name, repository path or tag is wrong, check those values before escalating privileges. A permission error is not fixed by changing a tag to latest.

6. Choose a platform only when needed

Multi-platform images can publish different manifests for different CPU and operating-system combinations. Let Docker choose the host platform by default. If a build or test deliberately needs another supported platform, pass the platform shown in the publisher's documentation:

$ docker image pull --platform linux/amd64 IMAGE_NAME:TAG

This can download an image that is not native to the host. Pulling it does not make every program inside it compatible with your hardware. Verify the target platform as part of the build or runtime workflow, rather than adding the option to every command by habit.

7. Limit scope and recover from mistakes

By default, one tagged image is pulled. --all-tags downloads every tagged image in a repository, which can consume much more storage and bandwidth:

$ docker image pull --all-tags IMAGE_REPOSITORY

Use that option only when you genuinely need the complete repository. If a pull is taking too long, press Ctrl-C in the terminal that started it. The client stops the operation when its connection to the Engine is lost. Do not delete partially downloaded storage by hand.

A pull does not provide a general undo command. If you downloaded the wrong completed image, identify it first:

$ docker image ls --filter reference=IMAGE_REPOSITORY
$ docker image rm IMAGE_REPOSITORY:WRONG_TAG

docker image rm changes local state and can fail when a container or another tag still refers to the image. Check the reference carefully before running it. Removing a tag may make the layers eligible for later cleanup, but it does not remove an image from a registry.

Common failure checks

  • Cannot connect to the daemon: check the Docker Engine service and socket access using your distribution's normal administration process. This is a host setup problem, not a registry image-name problem.
  • Unauthorised or denied: confirm the registry host and repository path, then authenticate with the registry's documented account. Avoid sharing the full error if it contains private repository names.
  • Manifest unknown: the requested tag or digest is not published for that repository. Check the release record instead of guessing a nearby tag.
  • Platform mismatch: remove an unnecessary --platform override or select a platform the image actually publishes.
  • Disk or network pressure: stop the pull if necessary, then check space and the daemon's configured download limits. Do not respond by deleting random files under Docker's storage directory.

Done means

  • The Docker client version and pull syntax were checked.
  • The intended repository and tag, or a trusted digest, are present in docker image ls.
  • Moving tags were not mistaken for immutable release identifiers.
  • Private registry credentials were kept out of commands and logs.
  • --platform and --all-tags were used only for an explicit requirement.
  • No container was started and no registry content was deleted.