8.3.2.3 Local Config Bind

Local config bind refers to bind-mounting a specific configuration file or directory from the host into a container, allowing local, environment-specific configuration to be supplied without needing to bake it into the image or pass it through numerous individual environment variables.

A Typical Local Configuration Bind

A configuration file maintained on the host is mounted directly into the container at the location the application expects to find it.

docker run -d -v $(pwd)/config/local.yaml:/app/config.yaml myapp:1.0

The application reads its configuration from /app/config.yaml exactly as it would in any other deployment, with the actual content sourced from this specific local file.

Why This Approach Suits Complex, Structured Configuration

For configuration too complex or structured to comfortably express through individual environment variables, a configuration file bind mount provides a more natural way to supply that complete structure.

database:
  host: localhost
  port: 5432
logging:
  level: debug
  format: json

docker run -d -v $(pwd)/config/dev.yaml:/app/config.yaml myapp:1.0

Switching Configuration by Changing the Bound File

Different environments or scenarios can use different configuration files, simply by changing which local file gets bind-mounted, without needing to modify the container or image at all.

docker run -d -v $(pwd)/config/dev.yaml:/app/config.yaml myapp:1.0
docker run -d -v $(pwd)/config/test.yaml:/app/config.yaml myapp:1.0

Keeping Local Configuration Out of Version Control When Appropriate

A locally bind-mounted configuration file containing developer-specific or sensitive values should typically be excluded from version control, kept as a local-only file referenced by the bind mount but never committed to the project's repository.

config/local.yaml

This pattern in a .gitignore file keeps locally specific configuration from being accidentally shared or committed.

Why Local Config Bind Matters

Bind-mounting configuration files provides a flexible, convenient way to supply complex, structured, or environment-specific configuration during local development, without requiring that configuration to be baked into an image or awkwardly expressed through many individual environment variables.