Docker Images Explained: Layers, Tags, and Digests

Introduction

An image — sometimes called a Docker image, container image, or OCI image — is a read-only package containing everything needed to run an application: source code, dependencies, a minimal set of OS constructs, and metadata. A single image can be used to start multiple containers.

Images vs Containers

Images are build-time constructs, while containers are their run-time counterpart — similar to how a class relates to an object, or a VM template relates to a running VM. Once a container is started from an image, the two become bound, and the image cannot be deleted until all containers using it are removed.

Because containers should run a single application, well-designed images avoid unnecessary tools such as shells or package managers. These minimal images are often called slim images, and since containers share the host's kernel, images don't need to include a full OS.

Pulling Images

Downloading an image from a registry is called pulling. Images are stored locally in what's known as the image cache. The following command pulls the official Redis image:

docker pull redis

By default, Docker assumes the latest tag and Docker Hub as the registry unless told otherwise.

Image Registries and Repositories

Images are stored in registries, which contain repositories, which in turn contain one or more images. Docker Hub is the most common registry, but others exist, including private, on-premises options.

Official repositories on Docker Hub are vetted images maintained by Docker and the application vendor, identifiable by a green badge and their position at the top level of the namespace (e.g. nginx, redis). Unofficial repositories, identified by a username or organization prefix, should be treated with more caution.

Naming and Tagging

A fully qualified image name includes the registry, organization, repository, and tag. Pulling from an official repository is straightforward:

docker pull redis:8.0-M02

If no tag is specified, Docker defaults to latest — though this tag is not guaranteed to point to the newest version of an image. A single image can also carry multiple tags simultaneously.

Images and Layers

Images are built from a stack of independent, read-only layers, each potentially containing one or more files. Docker presents these stacked layers as a single unified filesystem. Layers can be inspected using:

docker inspect redis:latest

Docker uses storage drivers — most commonly overlay2 — to merge these layers into one consistent view. Images can also share layers between each other, saving both disk space and network bandwidth during pulls.

Pulling Images by Digest

Because tags are mutable, they don't guarantee you're getting the same image every time. To solve this, every image has an immutable digest — a cryptographic hash of its content. Digests can be viewed with:

docker images --digests alpine

and used to pull an exact, verified version of an image regardless of what its tag currently points to.

Multi-Architecture Images

A single image tag can support multiple CPU architectures through a manifest list, which points to individual manifests for platforms like linux/amd64 or linux/arm64. This allows the same docker pull command to fetch the correct image automatically, regardless of the host's architecture.

Vulnerability Scanning

Tools such as Docker Scout scan images for known vulnerabilities and suggest remediation steps, integrating directly into the Docker CLI, Docker Desktop, and Docker Hub.

Deleting Images

Images can be removed with the docker rmi command, which deletes local layer data as long as no container or other tag still references the image.

Conclusion

Understanding how images are structured — as stacked layers identified by mutable tags but guaranteed by immutable digests — is fundamental to working reliably with Docker, especially in production environments where consistency and security matter most.