What is the difference between a Docker image and a container?
An image is a static, read-only template. A container is a running, or stopped, instance created from one. The relationship is close to that between a program on disk and a process running it: one image can produce any number of containers, each with its own writable layer and its own lifecycle.
Images are built in layers, each capturing the filesystem changes from one build instruction. Layers are shared between images, which is why pulling a second image based on the same foundation downloads far less than the first. They are also immutable, which is what makes builds cacheable and distribution efficient.
When a container starts, a thin writable layer is added on top. Everything the process writes goes there, leaving the image untouched. That is why two containers from one image do not see each other files, and why removing a container discards those changes unless they were written to a mounted volume.
Several practical consequences follow.
- Data written inside a container is ephemeral by default. Anything that must outlive the container needs a volume or bind mount.
- Stopping a container does not delete it. A stopped container still holds its writable layer and still occupies disk, which is why stopped containers accumulate and why listing all containers rather than only running ones is often surprising.
- Changing a running container does not change the image. To make a change permanent you rebuild, which is the basis of reproducible deployments.
The terminology overlaps in casual use, and people often say image when they mean container or the reverse. Keeping them distinct matters most when reasoning about state, because almost every question about where data went resolves to understanding which of the two is holding it.