Docker volume or bind mount: which should you use?

Compare the two storage models

Both can survive container removal. Neither is automatically a backup. With a remote Docker daemon, the bind source belongs to the daemon host, not necessarily to the computer where you type the command.

Observe persistence with a named volume

Choose a fresh volume name for this exercise. These commands use a small Alpine image; the first run may download it.

docker volume create devsheet-volume-demo
docker run --rm --mount type=volume,source=devsheet-volume-demo,target=/data alpine:3.22 sh -c "echo hello > /data/note.txt"
docker run --rm --mount type=volume,source=devsheet-volume-demo,target=/data alpine:3.22 cat /data/note.txt

Expected: hello on the second run. The first container was removed by --rm, while the explicitly named volume kept the file. The demo volume remains until you intentionally remove it.

Mount a host directory read-only

In Bash, create a new demo directory containing a file. The source must exist when using this bind-mount syntax.

mkdir devsheet-bind-demo
printf "hello\n" > devsheet-bind-demo/note.txt
docker run --rm --mount "type=bind,source=$(pwd)/devsheet-bind-demo,target=/data,readonly" alpine:3.22 cat /data/note.txt

Expected: hello from the host file. The readonly option prevents writes through this mount in the container. Docker Desktop may require permission to share that host directory. The host directory remains after the command.

Check mounts before trusting persistence

Mounting over a nonempty container directory hides its existing contents for the life of that mount. Confirm the path with docker inspect <container> and check the Mounts section.

A writable bind mount gives the container access to change host files at that path. Limit the exposed directory. For databases, use a backup method suitable for the database rather than copying live files without checking consistency.