Bind Mounts

A bind mount maps an existing host path into the container, both seeing the same files. Rebuilding the image for every code change is slow; mounting the source into node:24-slim and letting node --watch restart on changes gives a live development loop, as Docker Networking previewed:

docker run -d --name l3-dev --network l3-bn -p 33001:3000 -e PGHOST=postgres \
  -u "$(id -u):$(id -g)" -v "$PWD":/app -w /app node:24-slim node --watch server.js >/dev/null
sleep 3; curl -s localhost:33001/health; echo
sed -i "s/{ status: 'ok' }/{ status: 'ok', mode: 'dev' }/" app.js
sleep 2; curl -s localhost:33001/health; echo
docker logs l3-dev 2>&1 | grep -E 'Restarting|listening' | tail -2
docker exec l3-dev touch /app/made-in-container && ls -ln made-in-container
git checkout -q app.js; rm made-in-container; docker rm -f l3-dev >/dev/null

{"status":"ok"}
{"status":"ok","mode":"dev"}
Restarting 'server.js'
BookNest API listening on http://localhost:3000
-rw-r--r-- 1 1000 1000 0 Sep 25 18:39 made-in-container

The edit on the host reached the container at once and Node.js 2,131 restarted itself. Three pitfalls come with bind mounts. Ownership: the container writes with its own UID, so without -u a root process leaves root-owned files in your working tree. Shadowing: a mount hides whatever the image had at that path, including an image's node_modules; here the host's own node_modules from npm 2,036 install is used, and -v /app/node_modules (an anonymous volume) keeps the image's copy instead when the host has none or a different platform's. Reach: a writable bind mount of a sensitive path such as / or /var/run/docker.sock gives the container control of the host (Container Security). Add :ro, or readonly with --mount type=bind,src=...,dst=..., whenever the container only reads. Bind mounts are also slow on Docker Desktop 514 for macOS and Windows, where files cross a VM boundary; WSL2 6 files inside the Linux filesystem, as here, avoid that cost.