Docker Hub hosts more than 15 million images, and over 20 million unique IP addresses pull from it, which adds up to more than 16 billion pulls every month (Docker, 2024). Nobody is clicking download that many times by hand, so most of those pulls come from build servers and deployment scripts.
Each of those images is a read-only template holding an application, its runtime, and whatever dependencies it needs to run as one deployable unit.
Docker builds an image from a stack of read-only layers in the format standardized by the Open Container Initiative. A tag or a content digest tells you which version you have. Registries such as Docker Hub or Amazon ECR (GitHub Container Registry works too) store the images and hand them to any machine that pulls.
What Is a Docker Image
Nothing inside an image changes once it’s built.
Need an update? You build a new image. You never edit the old one.
This packaging approach is what people mean by containerization, and it’s the reason the same image behaves the same way on a laptop and on a production server.
Inside the image sits the application code and its compiled binaries, along with a minimal runtime such as an interpreter or a JVM.
- System libraries and shared dependencies
- Configuration files
- Default environment variables
- Whatever else the build copied in
The image is the template. Once Docker runs it as a live process, you have a container.
Layers, tags, and registry references all trace back to that one idea of a static, shareable package.
Docker Image vs Container vs Virtual Machine
Northflank’s 2026 comparison of containers and virtual machines puts container startup in the range of milliseconds. A traditional virtual machine takes anywhere from several seconds to a few minutes to boot a full guest operating system.
| Unit | What It Is | Startup Speed | Isolation Level |
|---|---|---|---|
| Docker image | Static, read-only template | Not applicable | None until run |
| Docker container | Running instance of an image | Under 1 second typically | Process-level, shared kernel |
| Virtual machine | Full simulated computer | Seconds to minutes | Hardware-level, own kernel |
A Docker container shares the host machine’s kernel instead of loading its own.
A virtual machine goes the other way. It boots a whole operating system, kernel included, inside a hypervisor.
So containers are lighter and faster, and virtual machines are more isolated. That’s really the whole trade.
Most production stacks end up running both. Docker handles application packaging day to day, and virtual machines still host the cloud infrastructure underneath it.
How Docker Image Layers Work
Every layer in a Docker image records one filesystem change, and all of them are read-only.
Docker merges the stack into a single usable filesystem through a union filesystem, most often OverlayFS on Linux hosts.
Union Filesystem and Layer Caching
Layer caching is why a second build of the same Dockerfile often finishes in seconds instead of minutes.
Each RUN, COPY, and ADD instruction produces its own layer, stacked on the one before it. Layers are content-addressed, so one stored copy serves every image that reuses it. And if nothing above a given line in the Dockerfile changed, Docker skips rebuilding that layer.
Only the instructions below a modified line get rebuilt. Everything above stays cached.
Image Manifest and Digests
The manifest is a JSON file listing every layer along with its size and media type. Run sha256 over that manifest and you get the digest, which is unique to the exact content of the image.
The Open Container Initiative standardizes this format, so an image built with Docker runs correctly on other OCI-compliant runtimes like containerd.
The OCI Image Specification reached version 1.1.0 on February 15, 2024, its first minor update since the original 1.0.0 release in July 2017 (Open Container Initiative).
That update added support for attaching metadata, such as software bills of materials, to an image through new subject and artifactType fields. The image’s underlying layer structure stayed the same.
How a Dockerfile Builds a Docker Image
A Dockerfile is a plain text file of instructions that Docker follows to assemble an image. Instructions such as RUN, COPY, and ADD each add a layer, while the rest only add metadata.
FROM sets the base image. RUN executes a command and commits the result as a new layer.
COPY and ADD bring files from the build context into the image, and CMD sets the default command a container runs on start.
Docker reads all of this top to bottom. The build context, meaning the folder sent to the Docker daemon, decides which files are even available to copy.
Modern builds run through BuildKit, Docker’s build engine. It runs independent steps in parallel and skips anything unchanged.
In CI/CD, a build pipeline usually treats the Dockerfile build as one stage. Testing comes next, then a push of the finished image to a registry.
Multi-stage builds push this further. One stage compiles the application, and a second, smaller stage copies over just the finished binary.
The compilers, source code, and build dependencies from the first stage never reach the final image.
Docker Image Tags and Digests
A tag is a human-readable label attached to an image, like nginx:1.27 or myapp:latest.
Tags are mutable. Someone can push a new image under the same tag tomorrow, and it now points somewhere else entirely.
Digests don’t have that problem. A digest uses the sha256 algorithm, runs 64 hexadecimal characters, and never changes, because it’s calculated from the image’s exact content.
When you don’t specify a tag, Docker applies latest. Version tags commonly follow a major.minor.patch pattern, which is what most people mean by semantic versioning, although plenty of image maintainers only follow it loosely.
Pulling by digest gets you the exact same image every time, byte for byte. Pinning to latest in production is a common mistake, since it looks stable but really isn’t.
Tools like Docker Compose let a team pin a service to a specific digest, which takes that ambiguity out of a multi-container setup.
Choosing a Base Image
The base image is the starting layer everything else in a Dockerfile builds on.
Pick a bloated one, and every derived image inherits the bloat along with its attack surface.
Alpine Linux is tiny, often just 5 to 8 MB, because it’s built around musl libc and BusyBox. The catch is that musl causes subtle bugs in software written and tested only against glibc.
Debian or Ubuntu gives you glibc compatibility, a familiar package manager, and a full shell for debugging. You pay for that with size. They carry a much larger package footprint than a minimal base.
Distroless images ship without a shell or a package manager, which gives you about the smallest realistic attack surface. Debugging gets harder, since there’s nothing to exec into.
Google’s own size comparison puts its smallest distroless image at roughly 2 MiB. That’s about half of Alpine’s roughly 5 MiB and less than 2 percent of Debian’s 124 MiB (GoogleContainerTools).
Scratch is an empty base with zero overhead, built for statically compiled binaries. No shell, no libc, no utilities. It only works for fully self-contained binaries, like the ones Go produces.
There’s no single right answer here. A Node.js app usually needs more than scratch offers, and a compiled Go binary rarely needs more than scratch provides.
Where Docker Images Are Stored
Docker images live in a registry, a server built to store images and serve them back to any machine that asks.
That’s the basic idea behind a container registry. Storage is centralized, and authorized systems pull from it on demand.
Docker Hub is the default public registry, but AWS, GitHub, and self-hosted setups all do the same job.
| Registry | Hosting Type | Access Control | Typical Use |
|---|---|---|---|
| Docker Hub | Public, Docker-run | Public or private repos | Open source projects, small teams |
| Amazon ECR | Private, AWS-managed | IAM policies | AWS-hosted workloads |
| GitHub Container Registry | Public or private, GitHub-managed | GitHub repo permissions | Projects already hosted on GitHub |
| Harbor | Self-hosted, open source | Role-based, org-managed | Enterprises needing full control |
Docker’s early-2021 Docker Index counted 318 billion all-time pulls on Docker Hub, up 145 percent year-over-year, with nearly 30 billion pulls in the fourth quarter of 2020 alone (Docker, 2021). By August 2021, the all-time total had reached 396 billion.
Pushing uploads an image to a registry. Pulling brings it down to a local machine or a build server.
Docker only transfers the layers a machine doesn’t already have cached locally.
That’s why pulling a second image with the same base is usually much faster than the first pull ever was.
Private registries restrict who can pull an image at all, which matters once the image contains proprietary code or internal configuration.
Building a Docker Image Step by Step
The build order stays the same no matter what the application does.
- Write a Dockerfile that lists a base image, the files to copy, and the command to run
- Run docker build with a tag, pointing it at the folder containing the Dockerfile
- Let Docker read the build context, execute each instruction, and stack the resulting layers
- Inspect the finished image with docker inspect or docker history to confirm what landed inside
- Push the tagged image to a registry so other machines can pull it
Most of the real work happens in step three, since caching, base image size, and instruction order all interact there.
A build that fails halfway through usually means one instruction assumed a file existed in the build context when it didn’t.
Keep the Dockerfile and the code it packages in the same directory whenever you can. The build context stays small and predictable that way.
Once it’s built, the finished image is really a build artifact. You can push it, tag it, store it, and reuse it without rebuilding from scratch.
Reducing Docker Image Size
A smaller image pulls faster, scans faster, and costs less to store.
On that last point, Amazon charges $0.10 per GB-month for private image storage on Elastic Container Registry (AWS, 2026). Registry costs scale directly with image size, so a bloated image isn’t just slow. It’s a recurring bill.
Switching the base image alone, without touching application code, is often the single biggest size lever available. Multi-stage builds go after the rest by dropping the compiler, headers, and source code out of the final image entirely.
Pick the smallest workable base and use multi-stage builds so build tools stay out of the final image. Then clean up package manager caches in the same RUN instruction that installed them.
That last habit comes down to layer caching. A separate apt-get clean in its own instruction doesn’t shrink anything, since the earlier layer already committed the larger size.
Combining install and cleanup into one RUN line is what actually removes the extra weight from the layer.
Securing a Docker Image
Sysdig’s 2023 Cloud-Native Security and Usage Report found that 87% of container images running in production carry high or critical vulnerabilities.
The same report found that only 15% of the high and critical vulnerabilities with an available fix sit in packages actually loaded at runtime.
That gap matters. Scanning tells you what’s present, but exploitability depends on what code actually executes.
Tools like Trivy and Docker Scout scan an image’s layers against known CVE databases. Docker Content Trust and cosign-based signing go a different direction and verify that an image hasn’t been tampered with after it was built.
Scanning inside CI, before a push, catches problems before they ever reach a registry.
A smaller base image, covered above, also shrinks the list of packages a scanner has to check in the first place.
Running containers as a non-root user limits what an attacker can do even after gaining code execution inside one.
When a Docker Image Does Not Apply
A Docker image doesn’t fit every workload. Some jobs need a different unit of packaging entirely.
Compliance rules that demand a separate kernel per workload rule containers out, because they share a kernel. A virtual machine, not an image, is the right unit there.
Stateful data is another mismatch. An image is read-only by design, so databases and file stores that need to persist data belong in a mounted volume, never baked into the image layers themselves.
Docker was built for server-side and CLI workloads, which makes GUI-heavy desktop software an awkward fit. Packaging a full desktop application inside an image is possible but rarely worth the added complexity.
Security concerns are part of why some organizations hold back entirely. CNCF’s 2023 Annual Survey found that 40% of organizations consuming cloud services named security as their leading challenge with container adoption (CNCF, 2023).
None of this makes Docker images the wrong choice in general. Containerizing something is a decision, not a default.
Essential Docker Image Commands
A handful of commands cover most day-to-day work with images.
| Command | What It Does |
|---|---|
| docker images | Lists every image stored locally |
| docker inspect | Shows an image’s metadata, layers, and configuration |
| docker history | Displays each layer and the instruction that created it |
| docker rmi | Removes a specific image by name or ID |
| docker image prune | Deletes unused, dangling images to reclaim disk space |
docker images is usually the first stop, since it shows what’s already on a machine before you pull anything new.
docker rmi fails if a container, running or stopped, still references that image.
Stop or remove the container first, and the image comes off cleanly. Guides on how to remove Docker images usually cover this exact ordering.
Running docker image prune regularly keeps a development machine from quietly filling up with old, unused layers.
FAQ on What Is A Docker Image
What Is Inside a Docker Image
Application code, a minimal runtime, system libraries, and configuration files, all packed into read-only layers.
A manifest describes those layers and their order. Nothing executes until Docker runs the image as a container.
Is a Docker Image the Same as a Kubernetes Container Image
Yes. Kubernetes does not define its own image format.
It pulls OCI-compliant images, the same format Docker produces, from a container registry and runs them through containerd or a compatible runtime, not through Docker itself.
What CPU Architectures Do Docker Images Support
Multiple ones, including amd64 and arm64, through multi-platform manifests.
A single tag can point to different builds per architecture, so the same command pulls the correct variant for Intel, AMD, or Apple Silicon hardware automatically.
How Much Does It Cost to Store Docker Images
It depends on the registry. Docker Hub offers free public repositories, while private registries like Amazon ECR bill by gigabyte stored per month.
Larger, unoptimized images and old, untagged versions left behind quietly drive that bill upward over time.
What Common Errors Happen When Building a Docker Image
Most build failures trace back to a missing file in the build context, a broken base image tag, or a RUN instruction that assumes a package already exists.
Cache invalidation from reordered instructions causes slow builds, not broken ones.
How Long Does a Docker Image Take to Build
Base image size, layer caching, and network speed for pulling dependencies all play a part.
A cached rebuild often finishes in seconds. A cold build that pulls a large base image and compiles code takes noticeably longer.
What Should You Fix First in What Is A Docker Image?
Start with the base image. Every vulnerability, byte, and layer stacked above it inherits whatever that starting point carries.
Multi-stage the build next, then scan and sign before pushing.
Sysdig’s finding that 87% of images running in production carry a high or critical vulnerability comes from images in its customers’ environments, so it isn’t a rate for Docker Hub as a whole. It does show why scanning belongs before the push, not after the deploy.
Even a clean scan doesn’t mean a registry will accept every image. The OCI Distribution Specification recommends that registries support image manifests of at least 4MiB, and each registry sets its own limit, usually answering an oversized push with a 413 error (Open Container Initiative, 2024).
Understanding the image is only half the picture. Running Docker on a machine is the next step, covered in our walkthrough on installing Docker.
- How to Turn On Dark Mode in Notepad++ (Built-In, No Plugin) - October 3, 2026
- PostgreSQL Cheat Sheet - October 2, 2026
- How to Repair a Corrupt SQL Server Database Without Any Data Loss - October 2, 2026
