Docker Volumes and Bind Mounts
A container can disappear while some of its data still matters. The first design question is where that data should live: in storage managed by Docker or at a specific path on the host.
Docker exposes those choices through volumes and bind mounts.
The Two Storage Boundaries
| Mount type | Storage is chosen by | Good fit |
|---|---|---|
| Named volume | Docker, under a name supplied by the user | Application data that another container may need to attach later |
| Anonymous volume | Docker, without a reusable user-chosen name | Container-managed data that does not need an obvious external handle |
| Bind mount | The user, as a host filesystem path | Source code or other host files that should be directly visible inside the container |
The important distinction is ownership of the path. A volume gives Docker responsibility for the storage location. A bind mount connects a particular host path to a particular container path.
Named Volumes
A named volume separates stored data from the lifecycle of one container. The name lets a later container attach the same storage.
docker run \
-v feedback:/app/feedback \
feedback-app
Here, feedback identifies Docker-managed storage and /app/feedback is where the container sees it.
An anonymous volume omits the name:
docker run -v /app/temp feedback-app
That can give a container a separate writable location, but the missing human-chosen name makes deliberate reuse less obvious. Use a named volume when reconnecting the data is part of the design.
Bind Mounts
A bind mount exposes a host directory inside the container:
docker run \
-v "$(pwd):/app" \
feedback-app
Changes made in the current host directory become visible at /app in the container. This is useful during development because an editor on the host and a process in the container can work with the same source tree.
A bind mount can be read-only when the container should observe the files without changing them:
docker run \
-v "$(pwd):/app:ro" \
feedback-app
Read-only access narrows what the container can do to the mounted workspace. Other paths can still use named or anonymous volumes when they need writable storage.
Choosing a Mount
Ask who should manage and inspect the data:
- Choose a named volume when the data belongs to the containerized application and must be attachable by name.
- Choose a bind mount when the host and container intentionally share a known directory.
- Use read-only bind mounts when the container only needs to consume host files.
- Treat anonymous volumes as unnamed storage whose later reuse is not the main workflow.
Mounts solve a storage-boundary problem. Port exposure, process identity, and image selection are separate concerns covered by containerized local tools.