Docker Compose Tip #77: Volume subpath for mounting a sub-directory

Named volumes are great for keeping data alive across container restarts. The default behavior mounts the entire volume root at the container target. Sometimes you want to mount only a sub-directory — for instance, a single service among many sharing the same named volume, each scoped to its own directory. The subpath option does exactly that. The basic shape services: app: image: myapp volumes: - type: volume source: shared-data target: /app/data volume: subpath: app volumes: shared-data: The named volume shared-data exists once on the host. The app container sees only the app/ directory of it mounted at /app/data. Other directories in shared-data are invisible to app. ...

June 17, 2026 · 4 min · 642 words · Guillaume Lours

Docker Compose Tip #67: Controlling image pulls with pull_policy

By default, Compose pulls an image when it’s missing locally and uses the cached one otherwise. pull_policy lets you change that behavior per service. The policies services: web: image: nginx pull_policy: always Available values: missing (default when no build: is defined): pull only if the image is not present locally. Alias: if_not_present. Note: the latest tag is always pulled even with this policy. always: pull on every up, even if the local image is recent never: don’t pull, fail if the image is missing build: build the image, rebuilds even if it’s already present locally daily: check the registry if the last pull was more than 24 hours ago weekly: check the registry if the last pull was more than 7 days ago every_<duration>: check the registry if the last pull was older than the given duration. Units: w, d, h, m, s (or any combination, e.g. every_12h, every_30m, every_1d12h) When to use each always for development against a fast-moving tag: ...

May 25, 2026 · 3 min · 475 words · Guillaume Lours

Docker Compose Tip #61: Provider services for non-container dependencies

Not everything in your stack is a container. Managed databases, SaaS APIs, VPN tunnels, Kubernetes intercepts, all sit outside Docker but still need to be wired into your local environment. Compose 2.36 introduced provider services to declare and manage these alongside your containers. The syntax A provider service replaces image: with a provider: block: services: api: image: my-api:latest tunnel: provider: type: telepresence options: namespace: avatars service: api port: 5732:api-80 Two parts: ...

May 11, 2026 · 3 min · 446 words · Guillaume Lours

Docker Compose Tip #60: Declaring LLMs with the models section

LLMs are now first-class citizens in Compose. The models top-level key lets you declare which models your application needs and wire them into your services, all in the same Compose file. Basic usage Declare a model at the top level, reference it from a service: models: smollm: model: ai/smollm2 services: app: image: myapp models: - smollm When the stack starts, Compose ensures the model is available locally and connects the app service to it. The container receives endpoint information via environment variables. ...

May 8, 2026 · 2 min · 381 words · Guillaume Lours

Docker Compose Tip #58: Using configs for config files

You’ve used secrets for sensitive data (Tip #22). For non-sensitive config files like nginx.conf or prometheus.yml, there’s a parallel feature: configs. Basic usage Define a config at the top level, reference it in a service: configs: nginx_conf: file: ./nginx.conf services: web: image: nginx configs: - source: nginx_conf target: /etc/nginx/nginx.conf The file is mounted read-only inside the container at the target path. No need to declare a volume mount manually. ...

May 4, 2026 · 2 min · 309 words · Guillaume Lours