Hardcoding IP addresses in your containers? Docker Compose provides automatic DNS-based service discovery. Each service can reach another using just the service name. How it works Docker Compose creates a default network and registers each container with an internal DNS server. The DNS name matches the service name in your compose.yml. services: web: image: nginx environment: # Just use the service name! API_URL: http://api:3000 DB_HOST: postgres api: image: myapi environment: DATABASE_URL: postgres://user:pass@postgres:5432/mydb postgres: image: postgres:15 No configuration needed. The web service connects to api using http://api:3000, and api connects to postgres using the hostname postgres. ...

AI tools work better when they understand the setup. Here’s how to document Compose files effectively. Add context with comments Comments help AI understand what each service does: services: # Primary web application serving React frontend # Handles user authentication and API gateway web: image: myapp:latest ports: - "3000:3000" # Public facing port - update in .env for production environment: # Connection string to PostgreSQL - format: postgresql://user:pass@host:5432/db DATABASE_URL: ${DATABASE_URL} # JWT secret for auth - must be at least 256 bits JWT_SECRET: ${JWT_SECRET} depends_on: db: condition: service_healthy # Development only - remove for production volumes: - ./src:/app/src # Hot reload for development # PostgreSQL 15 database with PostGIS extension # Stores user data and geographic information db: image: postgis/postgis:15-3.3 environment: POSTGRES_DB: myapp POSTGRES_PASSWORD: ${DB_PASSWORD} # Never commit actual password volumes: # Initial schema and seed data - ./init.sql:/docker-entrypoint-initdb.d/01-init.sql # Persistent data storage - postgres_data:/var/lib/postgresql/data volumes: postgres_data: # Named volume for database persistence across container restarts File headers For bigger projects, add a header: ...

Need to access private Git repositories during build? Here’s how to do it securely with SSH. The setup Enable SSH forwarding in your compose.yml: services: app: build: context: . ssh: - default # Uses your default SSH agent Or use specific keys for different services: services: app: build: context: . ssh: - github=/home/user/.ssh/github_key # Custom key for GitHub - gitlab=/home/user/.ssh/gitlab_key # Different key for GitLab The Dockerfile Use BuildKit’s SSH mount to clone private repos: ...

“Connection refused” errors? The app starts before the database is ready. Here’s the fix. What doesn’t work This only waits for the container to start, not for it to be ready: services: app: depends_on: - db # Container starts, but database isn't ready yet What actually works Add health checks: services: db: image: postgres:16 environment: POSTGRES_PASSWORD: secret healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 5 start_period: 10s app: image: myapp depends_on: db: condition: service_healthy # Now it actually waits for the database Common health checks PostgreSQL: ...

Same compose.yml, different environments. Here’s the cleanest approach. Basic setup Create different env files for each environment: .env.dev DATABASE_URL=postgresql://localhost:5432/dev_db API_KEY=dev_key_12345 LOG_LEVEL=debug REPLICAS=1 .env.prod DATABASE_URL=postgresql://prod-db.example.com:5432/prod_db API_KEY=${SECURE_API_KEY} # From CI/CD secrets LOG_LEVEL=error REPLICAS=3 How to use them # Development docker compose --env-file .env.dev up # Production docker compose --env-file .env.prod up # Override specific vars API_KEY=test_key docker compose --env-file .env.dev up Layering configs You can use multiple env files: # Base + environment-specific docker compose \ --env-file .env.base \ --env-file .env.prod \ up Note: Later files override earlier ones. ...