Pebellslearn by building
0%
RoadmapsMatrixCoursesSandboxSign in
Data Persistence  ›  Capstone Project

Bind Mounts

Bind Mounts 14 minA bind mount maps a specific folder or file from the host into the container, which is ideal for live-editing code in development but ties the container to the host's layout and permissions.

Bind Mounts

While developing quicknotes, rebuilding the image after every one-line change is painfully slow. You want to edit app.py in your editor and have the running container see the change at once. That needs the container to look directly at a folder on your machine: a bind mount.

The rule

A bind mount is a window from the container onto a host folder.

A bind mount maps an existing file or folder on the host to a path inside the container. There is no copy: both sides see the same files, live.

docker run -d --name notes-dev -p 8080:5000 \
  -v "$PWD":/app \
  quicknotes:1.0

The left side of -v is now a path, so this is a bind mount. The --mount form is --mount type=bind,source="$PWD",target=/app. Things to know:

  • It hides what was there. The code the image copied into /app is covered by your folder while the mount is in place. In development that is exactly the point.
  • :ro makes it read-only: -v /etc/quicknotes/config.toml:/app/config.toml:ro. The app can read the file but never change it.
  • Permissions come from the host. The kernel compares numeric UIDs, so if the container's user has a different UID from the files' owner, it may be refused.
  • It ties the container to one machine's layout. The path must exist on that host, which is why bind mounts suit development and host-provided config, while volumes suit application data.
  • It can reach anything. Mounting / or /var/run/docker.sock gives a container great power over the host. Mount only what you need.

With the code bind-mounted, you can make the app reload when files change. That is a job for your framework's development server, not for Docker; Docker just makes the edits visible.

The shortcut

Choose by asking who owns the data's location? If the host owns it (your source code, a config file already on the server), use a bind mount. If Docker should own it (app data that must just persist), use a named volume.

Three kinds of quicknotes storageStep 1 of 4

  1. Live source code

    Lives in your project folder; you edit it on the host. Host owns it: -v "$PWD":/app.

Drills

Answer fast — trust the rule.

quick drill

Which flag creates a bind mount?

quick drill

The image has code in /app, and you bind-mount your project folder onto /app. What does the container see there?

quick drill

How do you stop a container changing a bind-mounted config file?

quick drill

For quicknotes' production notes data on a server, which is the better fit?

quick drill

A bind-mounted folder gives "permission denied" inside the container although the names look right. What is the likely cause?

Remember

  • A bind mount is a window from the container onto a host folder: same files, live.
  • Shortcut: host owns the location → bind mount; Docker should own it → named volume.
  • Trap: mounts hide the image's files at the target, permissions follow numeric UIDs, and broad mounts give broad power.

Practice — level up

0/1 solved

Write your answer, then compare it with a rubric and a model answer.

ExplainVolume or bind mount?

For quicknotes you need three things: live code edits during development, the production notes data, and a read-only config file from the host. Choose a named volume or a bind mount for each, write the -v flag, and justify each choice.