12.1.1.1 Dev Source Bind

Dev source bind connects a project's source code directory directly into a development container through a bind mount, the foundational mechanism that allows code edited on the host to be immediately reflected inside the running, containerized development environment.

The Basic Source Bind Configuration

A project's root (or a specific source subdirectory) is bind-mounted into the container at the path the application expects its code to reside.

services:
  app:
    build: .
    volumes:
      - .:/app

Every file within the project's root directory on the host is directly accessible at /app inside the container, reflecting any edit immediately.

Why This Specific Bind Is Central to the Development Experience

Without this bind, a code change would require rebuilding the image for it to take effect inside the container — the source bind is what removes this friction, providing the live, immediate feedback loop developers expect during active development.

docker compose build app

echo "console.log('test')" >> src/index.js

With the source bind in place, this edit is immediately visible inside the container without needing the rebuild the first command represents.

Combining the Source Bind With an Excluded Dependency Path

To avoid the common dependency folder conflict, an additional, separate mount typically excludes a path like node_modules from the broader source bind.

services:
  app:
    volumes:
      - .:/app
      - /app/node_modules

Verifying the Source Bind Is Working as Expected

Confirming a host-side edit is actually reflected inside the running container validates this configuration.

docker compose exec app cat src/index.js

Why Dev Source Bind Matters

This specific bind mount is the foundational piece enabling the live, immediate development feedback loop that makes containerized development genuinely practical, without it, every single code change would require a full image rebuild to actually take effect.