9.2.4.1 Compose Config Injection

Compose config injection describes the process by which a declared config's content actually becomes available inside a service's container, typically appearing as a file at a specified target path, allowing an application to read its configuration exactly as it would read any other file.

How Injection Works in Practice

A config declared at the top level is injected into a specific container path for each service that references it.

services:
  api:
    configs:
      - source: api-config
        target: /app/config.yaml

configs:
  api-config:
    file: ./local-config.yaml

From inside the api service's container, /app/config.yaml exists as a regular file, with content matching ./local-config.yaml from the host, injected automatically when the container starts.

Customizing the Injected File's Permissions

The injected file's ownership and permission mode can be specified explicitly, useful when an application has specific expectations about a configuration file's access permissions.

services:
  api:
    configs:
      - source: api-config
        target: /app/config.yaml
        mode: 0440

configs:
  api-config:
    file: ./local-config.yaml

Injecting Multiple Configs Into the Same Service

A single service can have several distinct configs injected, each appearing at its own specified target path.

services:
  api:
    configs:
      - source: app-config
        target: /app/config.yaml
      - source: logging-config
        target: /app/logging.yaml

configs:
  app-config:
    file: ./app-config.yaml
  logging-config:
    file: ./logging-config.yaml

Verifying Injected Config Content

Confirming the injected file's actual content inside a running container validates that injection is working as intended.

docker compose exec api cat /app/config.yaml

Why Compose Config Injection Matters

Understanding exactly how and where a declared config's content becomes accessible inside a container is essential for correctly designing an application to read its configuration from the expected location, particularly when adapting an existing application to this mechanism for the first time.