Side by side
Docker ImagevsContainer
What is the difference between a Docker image and a container?
Updated 3 min read8 differences
In short
A Docker image is a read-only template holding an app and its dependencies; a container is a running instance of that image with its own writable layer.
Docker Image
A Docker image is a read-only, layered package of an application, its dependencies and settings, used as the template from which containers are started.
Read the page on Docker ImageContainer
A container is a lightweight, isolated package that bundles an application with its dependencies and runs it on the host's shared operating system kernel.
Read the page on ContainerDocker Image and Container compared
| Aspect | Docker Image | Container |
|---|---|---|
| What it is | A read-only template, stored as layers | A running or stopped instance of an image |
| State | Immutable: never changes after it is built | Has a writable layer that changes while it runs |
| Created with | docker build from a Dockerfile | docker run or docker create from an image |
| Lives in | A local image store or a registry such as Docker Hub | A host's container runtime, as isolated processes |
| Identified by | Name, tag and SHA-256 digest | Container ID and name |
| Count | Built once, then copied and reused | Many can run from one image at the same time |
| Uses | Disk space only | CPU, memory and network while running |
| Analogy | A class, or a recipe | An object, or a dish cooked from the recipe |
The difference, explained
A Docker image is a packaged, read-only snapshot of everything an application needs: its code, a runtime such as Node.js or Python, system libraries and default settings such as the start command. A container is what you get when you run that image: an isolated process on the host, with its own view of files, network and resource limits, plus a thin writable layer on top of the image. You build and store images; you start, stop and remove containers.
The relationship is like a class and its objects, or a recipe and the dishes cooked from it: one image can start any number of containers at once, and each one runs independently. When a container changes a file, the change goes into its own writable layer, so the image and every other container stay untouched. That is why an image is identified by a name, a tag such as postgres:17 and a content digest, while each container gets its own ID and name.
Their life cycles differ. An image is created with docker build from a Dockerfile, pushed to a registry and pulled onto any machine; it never changes, and a new version is a new image. A container is created with docker run, lives as long as its main process runs, and can be stopped, restarted or removed. Images built in the OCI format also run on containerd, Podman and Kubernetes, which is why they are also called container images.
A common misconception is that changes made inside a running container update the image. They don't: anything written to the container's layer is lost when it is removed, unless it went to a volume or was committed into a new image, which is rarely good practice. Another is that deleting a container deletes its image; the image stays until you remove it with docker rmi or a cleanup command.
Which one should you use?
Choose Docker Image when…
- You want to package an app once and ship the same thing to every environment.
- You change dependencies, the base system or the start command: edit the
Dockerfileand rebuild. - You need to version, scan or sign what you deploy.
- You want to share software through a registry such as Docker Hub.
Choose Container when…
- You want to actually run, test or debug the application.
- You need several isolated copies of the same app, each with its own ports and settings.
- You need to inspect a live process, read its logs or open a shell inside it.
- Settings differ per run, such as environment variables, volumes or resource limits.
One image, many containers (Docker CLI)
# Image: build a read-only template from a Dockerfile, then share it
docker build -t registry.example.com/shop-api:1.4 .
docker image ls # the image, stored once
docker push registry.example.com/shop-api:1.4# Containers: start running instances of that image
docker run -d --name api-1 -p 8001:3000 registry.example.com/shop-api:1.4
docker run -d --name api-2 -p 8002:3000 registry.example.com/shop-api:1.4
docker ps # two containers, one image
docker rm -f api-1 # the image is untouchedReaders ask
Can a container run without an image?
No. Every container starts from an image, which supplies its files and default settings; the container only adds a writable layer and runtime state on top.
Is a Docker image the same as a container image?
In practice, yes. Docker builds images in the OCI format, so the same image runs on containerd, Podman or Kubernetes, and "container image" is the tool-neutral name.
How do I keep changes made inside a container?
Put data that must survive in a volume, and put changes to the software itself in the Dockerfile and rebuild the image. docker commit can turn a container into an image, but the result is hard to reproduce.