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 #69: Sharing namespaces with pid and ipc

Linux isolates containers using kernel namespaces. Sometimes you need the opposite: two containers that can see each other’s processes or share memory. The pid and ipc directives give you that escape hatch. Sharing a PID namespace pid: service:<name> lets a container see and act on processes inside another service: services: app: image: myapp debugger: image: alpine pid: service:app cap_add: - SYS_PTRACE command: sleep infinity The debugger container’s ps, strace, and /proc all reflect app’s processes. Combined with cap_add: SYS_PTRACE, you can attach strace or gdb to a running production-style container without baking debug tools into its image. ...

May 29, 2026 · 3 min · 531 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

Docker Compose Tip #66: Volume drivers with NFS

Compose volumes default to local disk on the host running the container. When you need storage shared across hosts, a volume driver does the job. The built-in local driver already supports NFS through its options. Basic NFS mount Declare a volume that points to an NFS export: volumes: shared: driver: local driver_opts: type: nfs o: "addr=nfs-server.example.com,rw,nfsvers=4" device: ":/exports/shared" services: app: image: myapp volumes: - shared:/data The app service mounts /exports/shared from the NFS server at /data inside the container. Multiple containers (or even multiple Compose stacks on different hosts) can mount the same volume to share data. ...

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