Docker Compose Tip #51: docker compose up --wait for scripting and CI

docker compose up -d starts services in the background, but it returns immediately — before services are actually ready. --wait solves this by blocking until all services are healthy. The problem Without --wait, you often end up with fragile sleep-based scripts: # Fragile: how long is enough? docker compose up -d sleep 10 npm test The solution docker compose up --wait npm test --wait starts services in detached mode and blocks until every service with a healthcheck reports healthy. If a service fails to become healthy, the command exits with a non-zero status. ...

April 10, 2026 · 2 min · 354 words · Guillaume Lours

Docker Compose Tip #50: GPU support with deploy.resources

Running ML models, video processing, or any GPU-accelerated workload? Compose lets you reserve GPU devices for specific services. Basic GPU access Give a service access to all available GPUs: services: ml-training: image: pytorch/pytorch deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] Limiting GPU count Reserve a specific number of GPUs instead of all: services: inference: image: mymodel:latest deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] Selecting specific GPUs by ID Target specific GPU devices when you have multiple: ...

April 8, 2026 · 2 min · 296 words · Guillaume Lours

Docker Compose Tip #49: Mixed platforms with Linux containers and Wasm

Compose can orchestrate more than just Linux containers. By combining platform and runtime, you can run traditional containers alongside WebAssembly (Wasm) modules in the same stack. The platform key The platform key at service level tells Docker which platform the service targets: services: # Regular Linux container (default) web: image: nginx platform: linux/amd64 # WebAssembly module api: image: wasmedge/example-wasi-http runtime: io.containerd.wasmedge.v1 Mixing Linux and Wasm services Here’s a practical stack where a traditional nginx reverse proxy sits in front of a Wasm-based API: ...

April 6, 2026 · 2 min · 339 words · Guillaume Lours

Docker Compose Tip #48: Network debugging with docker compose port

When using dynamic port mapping or multiple services, it’s not always obvious which host port maps to which container port. docker compose port tells you exactly. Basic usage # Which host port maps to container port 80 on the web service? docker compose port web 80 # Output: 0.0.0.0:8080 Why dynamic ports matter When you let Docker assign ports automatically, the host port changes on every docker compose up: services: web: image: nginx ports: - "80" # Dynamic host port, container port 80 docker compose port web 80 # Output: 0.0.0.0:55432 (assigned dynamically) This is common in CI or when running multiple instances of the same project. ...

April 3, 2026 · 2 min · 320 words · Guillaume Lours

Docker Compose Tip #47: Sidecar container patterns

A sidecar is a helper container that runs alongside your main application, adding capabilities without modifying the application itself. Compose has specific features to make sidecars work seamlessly. Shared network namespace with network_mode Use network_mode: service:<name> to share the network stack with another container, they share the same IP address and can communicate over localhost: services: app: image: myapp # No ports needed — proxy handles public traffic proxy: image: nginx network_mode: service:app ports: - "443:443" volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro - ./certs:/etc/nginx/certs:ro Since both containers share the same network namespace, nginx can proxy to localhost:3000 without any DNS resolution. The app doesn’t need to know about TLS at all, the proxy sidecar handles it. ...

April 1, 2026 · 2 min · 360 words · Guillaume Lours