Docker Container vs Image: What's the Difference?

Docker beginners routinely mix up images and containers. They are related but fundamentally different things. The clearest analogy: an image is a class, a container is an instance. Or in everyday terms, an image is a blueprint and a container is the house built from it. You can build many houses from one blueprint, and each house can be lived in, modified, or torn down independently.

What Is a Docker Image?

A Docker image is a read-only template that packages an application together with everything it needs to run: the base OS layer, runtime, libraries, environment variables, and default command. Images are built once and can be reused, shared through registries like Docker Hub, and versioned with tags such as nginx:1.27.

Under the hood, an image is a stack of immutable layers. Only RUN, COPY, and ADD create new filesystem layers. Instructions like ENV, LABEL, CMD, ENTRYPOINT, EXPOSE, WORKDIR, USER, and ARG update image metadata but do not add a filesystem layer. Each filesystem-modifying instruction sits on top of the previous one. Layers are content-addressed and cached, so if two images share a base like python:3.12-slim, that layer is stored on disk only once. This is why pulling a second image from the same family is often nearly instant.

What Is a Docker Container?

A container is a running (or stopped) instance of an image. When you start a container, Docker takes the image's read-only layers and adds a thin writable top layer on top. Any file the process creates, modifies, or deletes lives in that writable layer, keeping the underlying image untouched. The container also has its own process namespace, network interface, and hostname.

Because containers add only a thin writable layer, you can launch dozens of containers from a single image without duplicating the base filesystem. When a container is removed, its writable layer is discarded, which is why persistent data belongs in volumes, not the container itself.

Side-by-Side Comparison

Aspect	Image	Container
State	Read-only, immutable	Read-write, mutable top layer
Lifecycle	Built, tagged, pushed, pulled	Created, started, stopped, removed
Filesystem	Stacked layers	Image layers + writable layer
Analogy	Class / blueprint / recipe	Instance / house / cooked meal
Storage location	/var/lib/docker/image	/var/lib/docker/containers
Runs a process?	No	Yes

The Commands That Reveal the Difference

• docker build -t myapp . - reads a Dockerfile and produces an image.
• docker pull nginx - downloads an image from a registry.
• docker images (or docker image ls) - lists the images stored locally.
• docker run nginx - creates and starts a container from the nginx image.
• docker ps - lists running containers; add -a to include stopped ones.
• docker rmi <image> vs docker rm <container> - different verbs for different objects.

How Layered Storage Works

Docker uses a union filesystem (typically overlay2) to stack layers. When a container reads a file, Docker searches down through the layers until it finds it. When the container writes to a file, the file is copied up into the writable layer first (copy-on-write) and then modified there. This keeps the base image pristine and makes container startup nearly instant, because nothing is actually copied at launch time.

Common Points of Confusion

• "I edited files in the container, why did they vanish?" Because docker rm deletes the writable layer. Use a volume or docker commit if you truly need to persist changes.
• "Why is my image so big but the container feels small?" The image carries the full OS plus dependencies; the container only adds a thin diff on top.
• "Can I run an image directly?" No. docker run looks like it runs the image, but it silently creates a container first.
• "Are images and containers stored together?" No, they live in separate directories under /var/lib/docker and are managed by different subcommands.

Rule of Thumb

If it sits on disk and never changes, it's an image. If it has a PID, an IP, and logs, it's a container. Build images, run containers, and reach for volumes whenever data needs to outlive either one.