Docker · Containers in practice
When would you use a bind mount instead of a volume?
Short answer
Bind mounts map a specific host path into a container. They suit local development and host integration, but couple the container to the host filesystem and its permissions.
A bind mount is a direct mapping from a host directory to a container path. Changes on either side are immediately visible, which is why it is popular for live-reload development. It also lets a container read host configuration or write to a specific host location.
docker run --rm -it -v "$(pwd)":/app -w /app node:20-alpine sh
docker run --rm -v /etc/localtime:/etc/localtime:ro alpine dateTrade-offs
- Tied to host paths, so the run command is not portable
- UID and GID mismatches cause permission errors
- File sharing performance on macOS and Windows can be slow
- A writable mount can let a container modify host files
- Read-only mounts reduce the risk for configuration files
Use bind mounts for development, for injecting a config file, or when the host path is the source of truth. Use a named volume for application data in production, because it is managed by Docker and does not depend on a particular directory layout.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Why do bind mounts often cause permission errors?
- 2What does the :ro suffix do?
- 3Why can bind mounts be slow on Docker Desktop?
- 4How do you choose between a bind mount and a named volume?
Say it in the interview
A bind mount maps a specific host directory into the container, so edits are visible on both sides. I use it for local development and for injecting host files, usually read-only for config. In production I prefer named volumes, because bind mounts tie the container to host paths and often create permission and portability problems.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Docker mock interview and get scored feedback on depth, clarity and confidence.