Stop 16 · Docker & ContainersTopics · 5/9

Volumes

In short

Containers are thrown away all the time, and everything written inside them goes too. Volumes are how your database survives a docker rm.

Docker's mechanism for persisting data outside a container's writable layer — essential for databases, since a container's own filesystem is wiped when it's removed.

The blob pushes a suitcase into a sturdy metal locker at a station cloakroom.

Think of it like this

The station cloakroom locker

You check out of a hotel room, and the room is cleaned for the next guest. Your suitcase, kept in the station cloakroom locker, is still there when you come back. The container is the hotel room; the volume is the locker.

Watch it happen

Two ways to keep files outside a container

Named volume

Docker manages where it's stored
Best for database data
Survives container removal

Bind mount

Maps a folder from your laptop
Best for live code in development
Edits show up instantly inside

Use named volumes for data the app owns, like Postgres files. Use bind mounts in development so code changes reach the container without rebuilding.

The big ideas

What you need to know

Container files are temporary

Anything written to the container's own layer disappears when the container is removed.

Mount at the data path

Each image stores data somewhere specific, like Postgres's data folder. Check its docs and mount the volume exactly there.

Back up volumes

A volume isn't a backup. For databases, use pg_dump or your host's snapshots on a schedule.

Bind mounts can hide files

Mounting a folder over /app hides what the image put there, including node_modules. Plan your mounts.

See it in code

Walk through the code

bash

1# Named volume: Docker manages where it lives2docker volume create pgdata3docker run -d --name db -e POSTGRES_PASSWORD=secret \4  -v pgdata:/var/lib/postgresql/data postgres:175 6# Delete the container, keep the data7docker rm -f db8docker volume ls          # pgdata is still there9 10# Bind mount: your project folder, live inside the container11docker run --rm -it -v "$(pwd)":/app -w /app node:22-alpine sh

1/3Create a named volume and mount it where Postgres keeps its data files.

Run the first docker run again with the same volume and your tables are all still there. That's the whole point.

Save yourself the pain

Common mistakes

Oops

Running Postgres in Docker with no volume for weeks.

Do this instead

One docker rm and the data is gone. Always mount a volume for databases.

Oops

Thinking a volume is the same as a backup.

Do this instead

Deleting the volume or a bad migration still loses data. Take real backups too.

Your mission

Make data survive

~20 min

Quick check

Your Postgres container is replaced during an upgrade. Where should its data live so it isn't lost?

Go deeper

1Add a volume to a database container and confirm data survives a container restart.
2Learn the difference between named volumes and bind mounts.
3Understand why you should never rely on a container's own filesystem for anything you need to keep.