Posts

This week, no Docker Compose tips, I’ll be at Devoxx France 2026 at the Palais des Congrès in Paris, from April 22 to April 24. I’m lucky to be on stage three times, with topics ranging from AI agents to a text-based RPG powered by tiny language models, and as you’d expect, containers and Compose are part of the story. Here’s what I’ll be talking about. Wednesday, April 22 — 17:50-18:20 (Tools-in-Action) Vos coding agents en mode YOLO… mais en toute sécurité There’s a term for what happens when you use AI coding agents heavily: permission fatigue. You end up clicking through approval prompts without really reading them. To work around this, tools now offer YOLO modes (trust-all-tools, bypass permissions…) that give agents full autonomy. ...

Not sure what docker compose up will actually do? Add --dry-run to preview every action without executing anything. Basic usage docker compose up --dry-run Compose shows exactly what it would do: DRY-RUN MODE - Container myapp-db-1 Creating DRY-RUN MODE - Container myapp-db-1 Created DRY-RUN MODE - Container myapp-web-1 Creating DRY-RUN MODE - Container myapp-web-1 Created DRY-RUN MODE - Container myapp-db-1 Starting DRY-RUN MODE - Container myapp-db-1 Started DRY-RUN MODE - Container myapp-web-1 Starting DRY-RUN MODE - Container myapp-web-1 Started Nothing is created, started, or modified. You just see the plan. ...

Every Compose stack gets a project name. It prefixes all resource names such as containers, networks, volumes. Understanding how it works avoids naming conflicts and makes multi-environment setups cleaner. Default behavior By default, the project name is the directory name where your compose.yml lives: my-app/ compose.yml docker compose up -d # Creates: my-app-web-1, my-app-db-1, my-app_default network Setting the project name Three ways to set it, in order of precedence: # 1. CLI flag (highest precedence) docker compose -p myproject up # 2. Environment variable COMPOSE_PROJECT_NAME=myproject docker compose up # 3. In the Compose file itself # compose.yml name: myproject services: web: image: nginx The name key in the Compose file is the recommended approach, it’s versioned with your code and everyone on the team gets the same project name. ...

Your development Compose file isn’t your CI Compose file. A dedicated CI configuration ensures tests run against a clean, seeded database with no leftover state. The development stack Take a typical full-stack project like dockersamples/sbx-quickstart — a FastAPI backend with a Next.js frontend and PostgreSQL: # compose.yml services: backend: build: ./backend ports: - "8000:8000" environment: DATABASE_URL: postgresql://postgres:postgres@db:5432/devboard depends_on: db: condition: service_healthy frontend: build: ./frontend ports: - "3000:3000" db: image: postgres:16 environment: POSTGRES_PASSWORD: postgres POSTGRES_DB: devboard volumes: - db-data:/var/lib/postgresql/data healthcheck: test: ["CMD", "pg_isready"] interval: 5s retries: 5 volumes: db-data: Adding a CI override Create a compose.ci.yml that adapts the stack for testing: ...

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. ...