Table of Contents
Understanding Docker Images
Docker images are the blueprints from which containers are created. They describe everything your application needs to run, including the operating system files, installed software, your application code, and default configuration. When you start working with Docker, images are one of the first core concepts you must understand, because every container you run is based on an image.
What a Docker Image Is
A Docker image is a read only package of files and metadata. You can think of it as a snapshot of a filesystem plus instructions that define how a container should start. The filesystem snapshot contains directories and files just like in a normal operating system. The metadata includes information such as which process to run by default, which ports the application expects to use, and environment variables.
Images are immutable. After an image is built, its contents do not change. If you need to update something, you create a new image. This immutability is one of the reasons images help achieve consistent behavior across different machines, whether on your laptop, a test server, or a production cluster.
Layers in Images
Internally, images are built from layers. Each layer represents a change to the filesystem, such as installing a package or copying in your application code. These layers stack on top of each other to form the full image. When Docker stores an image, it saves each layer only once, even if several images share that layer. This allows efficient disk usage and faster downloads, because unchanged layers can be reused.
Although the detailed explanation of image layers is covered separately, it is important to realize at this point that the layered structure is the reason images can be shared and cached efficiently. When you pull an image, Docker downloads all the layers that you do not already have and then combines them locally.
How Images Relate to Containers
A container is a running instance created from an image. The image provides the static part, the container adds a thin writable layer on top where runtime changes occur, such as temporary files or logs. Since the image itself stays unchanged, you can start many containers from the same image, and each container will have an identical starting point.
Because the image defines the base filesystem and startup configuration, it is common to hear people say they “ship an image” to move an application between environments. The exact same image can run in development, in testing, and in production, which reduces the chance of “works on my machine” problems.
An image is immutable and read only. Every running container adds its own separate writable layer on top of the image, so changing a container does not modify the original image.
Image Names and Tags
Every image has a name that identifies it. Commonly the name includes a repository and optionally a namespace, for example ubuntu, nginx, or mycompany/myapp. In addition to the name, images usually carry a tag. A tag is a label that points to a specific version of an image, such as nginx:1.25, python:3.12, or myapp:latest.
If you do not specify a tag when referring to an image, Docker uses the default tag latest. This default does not mean it is always the newest possible version, it simply means “the image that is currently tagged as latest.” Relying blindly on latest can lead to surprises when the underlying image changes without you noticing. The details of tags and versions are handled in a dedicated chapter, but at this stage it is important to see that a full image reference typically looks like repository:tag.
Where Images Come From
You rarely build all images from scratch. Most of the time you start from an existing base image and add your own files and configuration. Public images are hosted on registries, the most well known one is Docker Hub. From a registry, you can download images made by others, such as official images for popular programming languages, operating systems, and databases, then build on top of them for your own projects.
In professional environments, teams often maintain private registries that store their own application images. This allows them to control who can push and pull images and to manage versions in a central place. Registries and their use are covered elsewhere, but for understanding images it matters that images are portable artifacts that can be stored, versioned, and distributed like packages.
Official and Custom Images
Some images are published and maintained by organizations like Docker or the vendors of the software inside the image. These are often called official images. Examples include nginx, postgres, or node. They usually follow documented conventions and are updated regularly for security and bug fixes.
Alongside official images, you will create your own custom images for your applications. A custom image might start from a base like python:3.12 and then add your application files and dependencies. Over time, teams typically standardize on a set of base images that match their language and framework choices, and then derive project specific images from those bases.
Immutable Builds and Reproducibility
A key reason images are central to Docker workflows is reproducibility. Because an image records exactly which software and configuration it contains, you can rebuild or redeploy the same environment whenever needed. This is very different from manually configuring a server where changes over time are hard to track.
When you use images consistently, you aim for the rule that a given image reference always maps to the same content. In practice, this is easiest when you identify images by immutable identifiers called digests, which are discussed thoroughly in their own chapter.
For reliable and reproducible deployments, treat image references as immutable, and avoid changing the content that an existing, published tag points to.
Image Storage on Your System
On your local machine, Docker stores images in a special storage area that the Docker Engine manages. Every time you pull an image from a registry or build one yourself, Docker saves its layers locally. When you work with many images, this storage can grow and you may need to remove old or unused images.
Although the commands for listing and pruning images are explained in a later chapter, it is useful to know that Docker tries to reuse already downloaded layers automatically. This reusability speeds up both image pulls and builds and is a direct benefit of the layered image model.
Images in Day to Day Work
In daily Docker use, you will work with images constantly, even if you do not think about it explicitly. When you start a container, Docker retrieves the image if you do not have it already. When you change your application and rebuild, you produce a new image. When you deploy to another environment, you push an image to a registry and then pull it from there on the target system.
Because images have such a central role, understanding at a conceptual level that an image is a versioned, immutable, layered snapshot of an application environment will help you reason more clearly about how containers behave and what happens when you move workloads between machines.