Docker Compose

Define multi-container applications with proper dependency handling, networking, and volume management.

Security Scan

The skill is an instruction-only Docker Compose best-practices guide and its requirements and instructions are consistent with that purpose.

Purpose & Capability

Name/description match the content: the SKILL.md gives Docker Compose advice and the declared binary requirement (docker-compose or docker) is appropriate and proportional.

Instruction Scope

Instructions stay within Docker Compose usage: healthchecks, depends_on, volumes, .dockerignore, overrides, profiles and env precedence. Minor note: the example using the deploy.resources stanza may be misleading because 'deploy' settings are ignored by plain docker-compose (they apply to swarm/stack contexts), but this is a correctness/usability issue rather than a security concern.

Install Mechanism

No install spec and no code files — lowest-risk instruction-only skill. Nothing is downloaded or written to disk by the skill itself.

Credentials

Skill declares no environment variables or credentials. The SKILL.md references .env and Docker secrets as part of normal Compose workflows but does not request or attempt to access unrelated secrets or external credentials.

Persistence & Privilege

Skill is not always-enabled and does not request persistent privileges or modify other skills. It simply provides instructions that assume the user/agent can run Docker commands.

Assessment

This is an instruction-only guide for using Docker Compose; it does not install software or request credentials. Before using it, ensure the agent or environment that will execute these instructions actually has Docker/docker-compose installed and that you trust that agent to run container commands (those commands can create, modify, or delete containers and volumes — e.g., 'docker compose down -v' will delete volumes). Note the minor correctness point that 'deploy' resource limits are generally honored in swarm/stack deployments and may be ignored by local docker-compose; treat the SKILL.md as operational guidance, not an automated installer, and avoid running destructive commands on production systems without verification.

depends_on Ready Condition

• depends_on: alone only waits for container start—service likely not ready yet
• Add healthcheck + condition for actual readiness:

depends_on:
  db:
    condition: service_healthy

• Without healthcheck defined on target service, service_healthy fails

Healthcheck start_period

healthcheck:
  test: ["CMD", "pg_isready"]
  start_period: 30s

• start_period: initial grace period—health failures don't count during this time
• Slow-starting services (databases, Java apps) need adequate start_period
• Without it, container marked unhealthy before it finishes initializing

Volume Destruction

• docker compose down preserves volumes
• docker compose down -v DELETES ALL VOLUMES—data loss
• -v often added by habit from tutorials—catastrophic in production
• Named volumes survive down; anonymous volumes deleted on down

Resource Limits in Development

deploy:
  resources:
    limits:
      memory: 512M

• Set limits during development—catches memory issues early
• Unlimited container can consume all host memory—kills other processes
• Copy limits to production config—don't discover limits in prod

.dockerignore

• Without it: node_modules, .git, secrets copied into image
• Mirrors .gitignore syntax—create at same level as Dockerfile
• Large build context = slow builds, large images, potential security issues
• At minimum: .git, node_modules, .env, *.log, build artifacts

Override File Pattern

• docker-compose.yml: base config that works everywhere
• docker-compose.override.yml: auto-loaded, development-specific (mounts, ports)
• Production: docker compose -f docker-compose.yml -f docker-compose.prod.yml up
• Keep secrets and environment-specific config in override files, not base

Profiles for Optional Services

services:
  mailhog:
    profiles: [dev]

• Services with profiles don't start by default—cleaner docker compose up
• Enable with --profile dev
• Use for: test databases, debug tools, mock services, admin interfaces

Environment Variable Precedence

1. Shell environment (highest)
2. .env file in compose directory
3. env_file: directive
4. environment: in compose file (lowest for that var)

• .env must be exactly .env—.env.local not auto-loaded
• Debug with docker compose config—shows resolved values