8.3 Bind Mounts
A focused guide to Bind Mounts, connecting core concepts with practical Docker and container operations.
Bind mounts directly map a specific path on the host filesystem into a container, in contrast to a named volume's Docker-managed storage location, giving direct, immediate access to a host-chosen location's actual content from within the container.
Creating a Bind Mount
A bind mount is specified with an absolute host path on one side and a container path on the other.
docker run -d -v /home/user/app-config:/app/config myapp:1.0
This makes the host's /home/user/app-config directory directly accessible inside the container at /app/config, with changes from either side immediately visible to the other.
Why Bind Mounts Suit Local Development
A common use case mounts a project's source code directory directly into a container, allowing code changes made on the host to be immediately reflected inside the running container without needing to rebuild an image.
docker run -d -v $(pwd):/app -p 3000:3000 node:20-alpine npm run dev
Edits made to source files on the host are immediately visible inside the container, supporting a fast development feedback loop.
Key Differences From Named Volumes
A bind mount directly exposes a specific, pre-existing host location, requiring that location to already exist and be appropriately accessible — unlike a named volume, which Docker creates and manages internally, with no dependency on a specific pre-existing host path.
docker run -d -v mydata:/app/data myapp:1.0
docker run -d -v /home/user/mydata:/app/data myapp:1.0
The first uses a Docker-managed named volume; the second directly binds a specific host directory, requiring that exact path to already exist on the host.
Security Considerations of Bind Mounts
Because a bind mount provides direct access to a specific host path, a compromised container with a sufficiently broad bind mount could potentially read or modify host files beyond what was intended, making the chosen host path's scope an important security consideration.
docker run -d -v /:/host myapp:1.0
Mounting the entire host filesystem like this would be a serious security risk, demonstrating why bind mount scope should always be deliberately and narrowly chosen.
Why Bind Mounts Matter
Bind mounts provide a direct, flexible way to share specific host content with a container, particularly valuable for local development workflows, while requiring more careful consideration of host filesystem dependencies and security scope compared to Docker-managed named volumes.