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 #75: Silencing noisy services with attach: false

docker compose up streams logs from every service in a single terminal. That works fine for two or three services. With a stack that includes a chatty proxy, a healthcheck loop, or a model server printing tokenizer warnings every second, the signal-to-noise ratio drops fast. attach: false tells Compose to keep the service running but stop streaming its logs to the foreground. Per-service in the Compose file Mark the noisy service: ...

June 12, 2026 · 3 min · 479 words · Guillaume Lours

Compose Bridge Deep Dive #70 — Part 1: From Compose to Kubernetes

Compose excels at local development. Production usually runs on Kubernetes. Maintaining two parallel descriptions of the same application is where drift, bugs, and “works on my laptop” stories come from. Compose Bridge bridges that gap by turning a Compose file into a deployable Kubernetes artifact, without asking you to maintain a second source of truth. This is the first part of a three-post deep dive on Compose Bridge. Part 1 covers what it is and how it works. Part 2 goes into custom transformers and enterprise customization. Part 3 shows how to deploy an AI application with Docker Model Runner to Kubernetes. ...

June 1, 2026 · 4 min · 799 words · Guillaume Lours

Docker Compose Tip #68: Waiting for service exit with docker compose wait

docker compose up --wait (Tip #51) waits for services to become healthy. docker compose wait does something different: it waits for services to exit, and returns their exit code. Basic usage docker compose wait <service> The command blocks until the specified service stops, then prints the exit code. If you echo $? after, it’s the same value. This is perfect for one-shot services: migrations, batch jobs, test runners, anything that runs and exits. ...

May 27, 2026 · 2 min · 375 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