Why is data in a container temporary, and what are Docker volumes and bind mounts?

A container is like a hostel room you get for one semester. Anything you leave on the table belongs to that room, and when you check out, housekeeping clears it. If you want to keep your books, you put them in a locker that belongs to you, not to the room. Next semester you get a new room but the same locker.

A volume is a locker run by the hostel office (Docker): you just say "locker number 5" and they handle where it lives. A bind mount is your own almirah from home that you carry in: you choose exactly which one it is and where it sits.

# Without a volume: the data dies with the container
docker run -d --name db -e POSTGRES_PASSWORD=secret postgres:16
docker rm -f db           # a new container will start with an empty database

# Named volume: Docker manages the storage
docker volume create pgdata
docker run -d --name db -e POSTGRES_PASSWORD=secret \
  -v pgdata:/var/lib/postgresql/data postgres:16
docker rm -f db           # pgdata still exists; a new container can reuse it

# Bind mount: a host folder appears inside the container
docker run -d --name web -p 8080:80 \
  -v "$(pwd)/site:/usr/share/nginx/html:ro" nginx:1.27

In the bind mount example, editing a file in ./site on your laptop changes it inside the container immediately. The :ro makes it read-only for the container.

A container's filesystem is the image's read-only layers plus a thin writable layer. That writable layer belongs to the container. Stopping the container keeps it; docker rm deletes it. Since containers are meant to be replaced often (new version, crash, scale up, move to another server), anything important must live outside.

There are three kinds of mounts:

• Named volumes live in Docker's storage area (on Linux, under /var/lib/docker/volumes/). Docker creates and manages them, they work the same on every OS, and they are the recommended choice for databases and app data. When an empty volume is first mounted, Docker copies in any files the image already had at that path.
• Bind mounts map any host path into the container. They depend on the host's folder layout and file permissions, so they suit development rather than production.
• tmpfs mounts keep data in memory only. Good for temporary secrets or scratch files that must never hit disk.

The newer --mount syntax is more explicit than -v, for example --mount type=volume,source=pgdata,target=/var/lib/postgresql/data.

In local development, teams bind-mount their source code so changes show up without rebuilding the image. In production, databases use named volumes on a single host, or in Kubernetes they use PersistentVolumes backed by cloud disks such as AWS EBS. Stateless web servers often need no volume at all; they keep state in a database or object storage like S3.

• Running a database container with no volume and losing all data on the next redeploy.
• Saying data is lost when a container stops. It survives a stop; it is lost on removal.
• Using bind mounts in production and breaking when the host path or permissions differ.
• Mounting a bind mount over a folder the image needs, which hides the image's files at that path.
• Assuming docker rm removes named volumes. It never does (-v removes only anonymous volumes), so unused volumes pile up until you remove them with docker volume rm or docker volume prune.

• What is the difference between stopping and removing a container?
• How would you back up a Docker volume?
• How does persistent storage work in Kubernetes?
• Why might a bind mount cause file permission errors?