What is the difference between a Docker image and a container?

An image is like a recipe card for rajma chawal, and a container is the actual plate of food cooked from it. The card never changes when you cook. You can cook ten plates from the same card, and each plate can get its own extra pickle without changing the card or the other plates.

In programming terms, an image is like a class and a container is like an object created from that class.

# Download an image (the template)
docker pull nginx:1.27

# Start two separate containers from the same image
docker run -d --name web1 -p 8080:80 nginx:1.27
docker run -d --name web2 -p 8081:80 nginx:1.27

docker images    # lists images on this machine
docker ps        # lists running containers
docker ps -a     # also lists stopped containers

Both web1 and web2 come from one image stored once on disk. If you create a file inside web1, web2 does not see it, and the nginx:1.27 image itself stays unchanged.

An image is a stack of read-only layers, plus some metadata: the default command, environment variables, exposed ports and working directory. Each layer is a set of file changes. Images are built from a Dockerfile with docker build and identified by a name and tag, like nginx:1.27, or by a content digest like sha256:....

When you run a container, Docker takes those read-only layers and adds one thin writable layer on top using a union filesystem (overlay2 on most Linux hosts). Any file the container creates or changes goes into that writable layer. This is called copy-on-write: a file from the image is copied up only when the container modifies it. Because the image layers are shared, starting a hundred containers from one image does not copy the image a hundred times.

A container has a lifecycle: created, running, paused, stopped and removed. Stopping a container keeps its writable layer. Removing it with docker rm deletes that layer for good.

Teams build an image once in CI, push it to a registry such as Docker Hub, Amazon ECR or GitHub Container Registry, and then run the exact same image in testing, staging and production. This is what ends the "it works on my machine" problem: the image is identical everywhere, and only configuration such as environment variables changes between environments.

• Using the two words as if they mean the same thing.
• Editing files inside a running container and expecting the image to change. Those changes vanish when the container is removed. Fix the Dockerfile and rebuild instead.
• Relying on the latest tag in production. It moves over time, so two servers can end up running different code. Pin a version or a digest.
• Thinking each container stores its own full copy of the image.

• What is an image layer and why are layers shared?
• What happens to data inside a container when it is removed?
• What is the difference between an image tag and a digest?
• How does docker commit differ from building with a Dockerfile?