Docker Images vs Containers vs Volumes Explained

If you’ve used Docker for a week and still aren’t sure where the line sits between an image, a container, and a volume, you’re in good company. The three get blurred constantly because they’re related — one produces the next, and the third keeps your data alive across both. Mixing them up is where the “I deleted the container and lost my database” stories come from.

Here’s the short version, and the rest of this article backs it up:

• An image is a read-only blueprint. It doesn’t run.
• A container is a running instance created from an image. It’s where work happens.
• A volume is storage that lives outside any container, so your data survives.

Get these three clear and most of Docker stops feeling mysterious.

Images: the blueprint#

An image is a packaged, read-only template that contains everything needed to run something — the application, its dependencies, libraries, and a bit of configuration. It’s built once and never changes after that. When you run docker pull nginx:1.27, you’re downloading an image.

# Download an image without running anything
docker pull nginx:1.27

# List the images you have locally
docker images

The key word is read-only. An image just sits there. It doesn’t have a running process, an IP address, or logs. It’s the recipe, not the meal.

Images are built in layers, and those layers are shared. If two images both build on ubuntu:24.04, that base layer is stored once and reused. This is also why pulling a second image that shares layers with one you already have is fast — Docker only fetches what’s missing.

Containers: the running instance#

A container is what you get when you run an image. Docker takes the read-only image layers, adds a thin writable layer on top, and starts the process. That writable layer is where anything the container changes at runtime gets written — temp files, logs, an app’s scratch data.

# Create and start a container from an image
docker run -d --name web nginx:1.27

# See running containers
docker ps

# See all containers, including stopped ones
docker ps -a

A container has state. It can be running, stopped, paused, or removed. You can start and stop the same container repeatedly and it keeps its writable layer between stops — until you remove it.

That last point is the one that bites people. When you run docker rm web, the container’s writable layer goes with it. Anything stored only in that layer is gone. For a stateless web server that’s fine. For a database, it’s a disaster — which is exactly the problem volumes solve.

Volumes: storage that outlives containers#

A volume is storage managed by Docker that exists independently of any container. You mount a volume into a container at a path, the container reads and writes there, and when the container is removed the volume — and its data — stay behind.

# Create a named volume
docker volume create db-data

# Use it: mount the volume where Postgres keeps its files
docker run -d --name pg \
  -e POSTGRES_PASSWORD=change-me \
  -v db-data:/var/lib/postgresql/data \
  postgres:16

# List and inspect volumes
docker volume ls
docker volume inspect db-data

Now you can stop, remove, and recreate the pg container as many times as you like. As long as you mount the same db-data volume, the database is right where it was. The volume is the part that persists; the container is disposable.

There are two flavors worth knowing. A named volume (db-data) is managed entirely by Docker, which decides where it lives on disk. A bind mount maps a specific folder on your host into the container. Both persist data, but they behave differently around portability and permissions — the bind mount vs named volume guide breaks down which to pick. When it’s time to protect that data, see backing up Docker volumes.

How the three fit together#

Put it in order and the relationship is clean:

1. You pull or build an image — the read-only blueprint.
2. You run the image to create a container — a live instance with its own writable layer.
3. You mount a volume into the container — so the data you care about lives outside it.

A useful mental check whenever you’re about to delete something: ask which of the three you’re removing. docker rmi removes an image. docker rm removes a container. docker volume rm removes a volume. They’re different commands for different things, and Docker won’t let you remove an image that a container still depends on without forcing it.

What survives what#

This is the practical payoff, and it’s worth committing to memory:

• Remove a container (docker rm) → its writable layer is gone; volumes survive.
• Remove an image (docker rmi) → containers already running from it keep working; you just can’t start new ones from it until you pull again.
• Remove a volume (docker volume rm, or docker compose down -v) → the data is gone for good.

When you’re cleaning up disk space, the same distinction applies — it’s easy to reclaim space from unused images and stopped containers without touching volumes, but a careless prune can take volumes with it. The clean Docker images, containers, and volumes guide walks through doing it safely.

The one rule that prevents most pain#

If you remember nothing else: containers are disposable, volumes are not. Treat any container as something you can delete and recreate at will, and keep every piece of data you actually care about in a volume. Build that habit and the scary Docker moments — the ones where data disappears — mostly stop happening.

From here, the natural next steps are learning how containers talk to each other on a network and how to define multi-container setups in one file. The Docker networking guide and the Compose beginner guide build directly on the three concepts you just sorted out.