Infrastructure & Operations › Containers

Bind Mounts vs Volumes

Mounting a host directory vs Docker-managed storage.

Also known as: docker volume, bind mount, named volume

A container’s own filesystem is temporary: recreate the container and anything stored inside is gone (see ephemeral filesystem). To keep data or share it with the host, you mount something from outside. Docker gives you two main options.

A bind mount maps a directory or file on the host straight into the container:

docker run -v /home/me/app:/app myimage

You point at an exact host path. It’s what you want in development: edit code on your laptop and the container sees it immediately (see hot reloading in containers). The downsides: the path must exist, it’s tied to that one machine, and file ownership and permissions come with it — a process running as one UID may find files owned by another and fail to write.

A volume is storage Docker manages:

docker volume create pgdata
docker run -v pgdata:/var/lib/postgresql/data postgres

The volume lives under Docker’s own directory, not a path you chose. It’s portable, easy to back up or move, and the right choice for data that must outlive the container — database files, uploads. Anonymous volumes are the unnamed kind created automatically; name yours so you can find them later.

The classic mistake is keeping a database’s data inside the container image or writable layer, then losing it on the next docker compose up --build. Use a named volume for data.

Rough rule: bind mounts for source code, volumes for data. In Kubernetes the equivalent object is a persistent volume, and the same bind-versus-managed distinction applies. See Docker Compose for declaring mounts alongside the service.