A Docker image is an immutable template with an application's filesystem and its dependencies. A container is a running instance of that image, with its own process, network, and a writable layer for changes. One image can be run as a container any number of times, and each run gets an independent state. This layered model saves disk space, because shared base layers, such as a base operating system image, are not duplicated for every individual application image.
How an image differs from a container
A Docker image is built in layers: each build instruction adds its own layer on top of the previous one, and finished layers are reused between images. A container adds one more writable layer on top of the image, where any changes made while it runs land — new files, changed settings, temporary data.
- an image is stored on disk and in a registry, a container exists as long as its process is running
- one image can be run as several independent containers at the same time
- removing a container does not touch the image it was created from
Installing and setting up Docker on your own server is covered in the article setting up Docker on a VDS.
Comparing them by practical parameters
| Parameter | Image | Container |
|---|---|---|
| Mutability | immutable after the build | changes while it runs |
| Storage | server disk or an image registry | exists as long as the process is alive |
| State | has no state | keeps state in its own layer |
| Number of instances | one image is the source for many containers | each container is independent of the others |
Running several linked containers from several images with one command is covered in the article setting up Docker Compose.
What this looks like as a command
Creating a container from an image and starting it right away takes one command.
docker run --name web -d nginx:latestThe command looks for the nginx image with the latest tag, downloads it from the registry if needed, and creates a new container named web. The same nginx:latest image can be used to start as many containers as needed, under different names, without them affecting each other.
What to keep in mind during an update
Updating an application in Docker means building a new image, not changing a running container directly: any manual edits inside a container are lost when it is recreated, because they live in the writable layer, not in the image.
Moving an application to a new server or switching image versions is easier when configuration and data are kept outside the container — in environment variables and mounted volumes. The process of moving containers between servers is covered in detail in the article migrating Docker containers.
A separate tag for every image build is not a formality: without one, a new image can silently overwrite an old one with the same name, and rolling back to a working version turns into searching through build history instead of running one command. A tag is best tied to the application version or the CI build number, rather than left at its default value on a production server, where predictable deployments matter.
What to do when updating an image
An update is best done in the same order of steps every time, to avoid losing data.
- build a new image with the updated application under a separate tag
- make sure data and settings are kept outside the container, in volumes and environment variables
- stop and remove the old container, without touching the image it was created from
- start a new container from the updated image and check that it works
The old image is worth keeping on disk until the new container is confirmed to work correctly — a rollback then comes down to starting a container from the previous image again. This order reduces the risk of downtime during an update and makes it easier to diagnose any unexpected behavior in the new version.
Frequently asked questions
Can a Docker image be changed after it is built?
Not directly, an image is immutable after the build; to make changes, you need to build a new image with updated instructions and use it instead of the old one for new containers.
What happens to the data when a container is removed?
All data in the container's writable layer is lost along with it, which is why important data is kept in mounted volumes that are not removed together with the container.
How many containers can be started from one image?
As many as needed: an image is only a template, and each container started from it gets its own writable layer and runs independently of the rest.