Bind Mounts

In one line

Instead of letting Docker manage where data lives, you point directly at a specific folder on your own machine — the go-to tool for live-editing code during local development.

0/3 · 0%

Key ideas

01
A BIND MOUNT maps a SPECIFIC, EXPLICIT path on your host machine directly into the container — unlike a named volume, YOU choose and know exactly where the data lives on your host, because you're the one specifying the full host path.
02
Syntax: -v /full/host/path:/path/in/container (or --mount type=bind,source=/full/host/path,target=/path/in/container for the more explicit, verbose form). The key difference from a named volume is the LEFT side of the colon is a real host path, not a Docker-managed name.
03
The single most common real use case: live code editing during development. Bind-mount your local source code directory into the container running your dev server — edit a file in your normal editor on your host, and the running container sees the change INSTANTLY, since it's reading from the same actual files, no rebuild or restart needed for many frameworks with hot-reload.
04
This is fundamentally different from COPY in a Dockerfile: COPY takes a SNAPSHOT of files at BUILD time, baked into the image permanently. A bind mount is a LIVE, continuously-synced window into your host filesystem, active only while the container runs with that mount.
05
Bind mounts are less PORTABLE than named volumes — a bind mount's host path is specific to the machine you're running on ('/Users/yourname/project' won't exist on a teammate's or a production server's filesystem), which is exactly why named volumes (or no persistent mount at all) are strongly preferred for anything beyond local development.
06
Read-only bind mounts (-v /host/path:/container/path:ro) let a container READ host files without being able to modify them — useful for mounting in configuration files you want the container to see but never accidentally overwrite.

In your stack

→
A realistic Spring Boot dev-loop setup: bind-mount your project's src directory into a container running Spring Boot with devtools' auto-restart enabled — save a file in your IDE, and the container's Spring Boot process restarts itself automatically, without you ever rebuilding the Docker image during the entire development session.

Code & diagrams

bind-mount-devloop.shmarkdown

The exact command shape for a live-editing local development container.

# Bind-mount the CURRENT directory into the container, at /app.
# $(pwd) expands to your current absolute path — required, bind mounts need a full path.
docker run -it --rm \
  -v "$(pwd)":/app \
  -w /app \
  -p 8080:8080 \
  eclipse-temurin:17-jdk \
  bash

# Now, inside the container, any file you edit LOCALLY on your host
# is immediately visible inside /app — no rebuild, no restart of the mount.
# You could run: ./mvnw spring-boot:run  (with devtools for auto-restart on save)

# Read-only variant — the container can see but never modify this config
docker run -v "$(pwd)/config":/app/config:ro myapp:v1

Explain it without notes

You bind-mount your project folder into a container and edit a file locally — why does the container see the change instantly, with no rebuild step, unlike a normal Docker workflow?

Why would a team explicitly AVOID bind mounts for a production deployment, even though they're extremely convenient for local development?

Practice

Set up this topic's bind-mount dev-loop exercise with any small project you have, edit a file locally, and confirm the change is visible inside the running container without any rebuild.

Try mounting a directory as read-only (:ro) and attempt to write to it from INSIDE the container — observe and explain the error.

Trade-offs

↔
Bind mounts are unmatched for local development convenience but actively harmful to reproducibility if leaked into production configuration — a strong rule of thumb: bind mounts for docker run/docker-compose commands you type yourself during development, named volumes (or no persistent mount, relying purely on the image) for anything that gets deployed.

Done when you can

I can set up a bind-mount-based live-editing development workflow for a real project.
I know exactly why bind mounts are a poor fit for production deployments.
I can use a read-only bind mount when a container should see but never modify host data.

Command Palette