Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Docker and Docker Compose patterns for local development, container security, networking, volume strategies, and multi-service orchestration.
.claude/skills/docker-patterns/SKILL.md| Model | Eval pass | Runs |
|---|---|---|
| gemini-3.6-flashlowest | 96% | 26 |
| gemini-3.1-pro-preview | 100% | 1 |
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 108% | 0% |
| case-02 | ✗→✓ | ▲ Improved | 130% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 241% | 0% |
| case-12 | ✗→✓ | ▲ Improved | 82% | 0% |
| case-13 | ✗→✓ | ▲ Improved | 218% | 0% |
Docker and Docker Compose best practices for containerized development.
yaml# docker-compose.yml services: app: build: context: . target: dev # Use dev stage of multi-stage Dockerfile ports: - "3000:3000" volumes: - .:/app # Bind mount for hot reload - /app/node_modules # Anonymous volume -- preserves container deps environment: - DATABASE_URL=postgres://postgres:postgres@db:5432/app_dev - REDIS_URL=redis://redis:6379/0 - NODE_ENV=development depends_on: db: condition: service_healthy redis: condition: service_started command: npm run dev db: image: postgres:16-alpine ports: - "5432:5432" environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres POSTGRES_DB: app_dev volumes: - pgdata:/var/lib/postgresql/data - ./scripts/init-db.sql:/docker-entrypoint-initdb.d/init.sql healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 5s timeout: 3s retries: 5 redis: image: redis:7-alpine ports: - "6379:6379" volumes: - redisdata:/data mailpit: # Local email testing image: axllent/mailpit ports: - "8025:8025" # Web UI - "1025:1025" # SMTP volumes: pgdata: redisdata:
dockerfile# Stage: dependencies FROM node:22-alpine AS deps WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci # Stage: dev (hot reload, debug tools) FROM node:22-alpine AS dev WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . EXPOSE 3000 CMD ["npm", "run", "dev"] # Stage: build FROM node:22-alpine AS build WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . RUN npm run build && npm prune --production # Stage: production (minimal image) FROM node:22-alpine AS production WORKDIR /app RUN addgroup -g 1001 -S appgroup && adduser -S appuser -u 1001 USER appuser COPY --from=build --chown=appuser:appgroup /app/dist ./dist COPY --from=build --chown=appuser:appgroup /app/node_modules ./node_modules COPY --from=build --chown=appuser:appgroup /app/package.json ./ ENV NODE_ENV=production EXPOSE 3000 HEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http://localhost:3000/health || exit 1 CMD ["node", "dist/server.js"]
yaml# docker-compose.override.yml (auto-loaded, dev-only settings) services: app: environment: - DEBUG=app:* - LOG_LEVEL=debug ports: - "9229:9229" # Node.js debugger # docker-compose.prod.yml (explicit for production) services: app: build: target: production restart: always deploy: resources: limits: cpus: "1.0" memory: 512M
bash# Development (auto-loads override) docker compose up # Production docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d
Services in the same Compose network resolve by service name:
# From "app" container:
postgres://postgres:postgres@db:5432/app_dev # "db" resolves to the db container
redis://redis:6379/0 # "redis" resolves to the redis containeryamlservices: frontend: networks: - frontend-net api: networks: - frontend-net - backend-net db: networks: - backend-net # Only reachable from api, not frontend networks: frontend-net: backend-net:
yamlservices: db: ports: - "127.0.0.1:5432:5432" # Only accessible from host, not network # Omit ports entirely in production -- accessible only within Docker network
yamlvolumes: # Named volume: persists across container restarts, managed by Docker pgdata: # Bind mount: maps host directory into container (for development) # - ./src:/app/src # Anonymous volume: preserves container-generated content from bind mount override # - /app/node_modules
yamlservices: app: volumes: - .:/app # Source code (bind mount for hot reload) - /app/node_modules # Protect container's node_modules from host - /app/.next # Protect build cache db: volumes: - pgdata:/var/lib/postgresql/data # Persistent data - ./scripts/init.sql:/docker-entrypoint-initdb.d/init.sql # Init scripts
dockerfile# 1. Use specific tags (never :latest) FROM node:22.12-alpine3.20 # 2. Run as non-root RUN addgroup -g 1001 -S app && adduser -S app -u 1001 USER app # 3. Drop capabilities (in compose) # 4. Read-only root filesystem where possible # 5. No secrets in image layers
yamlservices: app: security_opt: - no-new-privileges:true read_only: true tmpfs: - /tmp - /app/.cache cap_drop: - ALL cap_add: - NET_BIND_SERVICE # Only if binding to ports < 1024
yaml# GOOD: Use environment variables (injected at runtime) services: app: env_file: - .env # Never commit .env to git environment: - API_KEY # Inherits from host environment # GOOD: Docker secrets (Swarm mode) secrets: db_password: file: ./secrets/db_password.txt services: db: secrets: - db_password # BAD: Hardcoded in image # ENV API_KEY=sk-proj-xxxxx # NEVER DO THIS
Use containers to test installer behavior against disposable project copies without allowing the test to mutate the source checkout.
Do not claim that a Linux container validates macOS or Windows behavior.
tmpfs workspace before any mutation./workspace with noexec, UID/GID 1000, and mode=0700 so only thecontainer user can inspect project data.
NPM_CONFIG_CACHE=/tmp/npm-cache onthe executable /tmp mount. Its default size is 2 GiB and can be adjusted with ECC_TMPFS_SIZE; ECC_WORKSPACE_SIZE separately controls the private workspace mount.
read_only: true, no-new-privileges:true, cap_drop: [ALL], and a finite pids_limit.network_mode: none. Add network accessonly through a visibly named opt-in service for an authenticated provider session; never make it an accidental environment-driven default.
dry-run, install,plugin, and shell modes.
spawnSync(..., { shell: false }) for cross-platform runners. Never interpolate project paths into a shell command.Use docker/plugin-setup/compose.yaml as the reference implementation. It provides:
fixture-tests for the focused install manifest, target, and executor suite.real-cli for the pinned Debian-based generic Linux image.real-cli-ubuntu for the pinned Ubuntu image.Validate the Compose model before building:
bashdocker compose -f docker/plugin-setup/compose.yaml config --quiet
Build both real Linux images:
bashdocker compose -f docker/plugin-setup/compose.yaml \ build real-cli real-cli-ubuntu
Run the safe default flow in each image:
bashdocker compose -p ecc-plugin-debian-test \ -f docker/plugin-setup/compose.yaml \ run --rm -T real-cli dry-run docker compose -p ecc-plugin-ubuntu-test \ -f docker/plugin-setup/compose.yaml \ run --rm -T real-cli-ubuntu dry-run
The dry run executes the current public command contract:
bashecc install --profile core --target claude-project --dry-run --json
Before that command runs, the container creates a locally packed npm artifact from the read-only checkout with npm pack --ignore-scripts. It extracts the self-created tarball under /tmp, validates the ecc-universal package name, required install manifests, and the confined package.json bin.ecc mapping, then invokes the extracted ecc executable. The runtime stays on network_mode: none, does not execute package lifecycle scripts, and does not rely on host node_modules; its exact pinned production dependencies are already present in the image.
The harness rejects an empty plan, a non-claude-project target, any operation outside /workspace/project/.claude, or any dry run that creates the target directory. install performs the isolated apply twice, checks its managed install state, lists the installed target, and runs doctor.
Start a detached container without --rm so leaving a terminal does not remove the session:
bashdocker compose -p ecc-plugin-session \ -f docker/plugin-setup/compose.yaml \ run --detach --name ecc-plugin-shell real-cli shell
The container copies the read-only fixture to the stable private directory /workspace/project. Confirm it is running, then emit the Docker side of the terminal-opener v1 data contract:
bashdocker inspect --format '{{.State.Running}}' ecc-plugin-shell node docker/plugin-setup/interactive-plan.js \ --container ecc-plugin-shell \ --workdir /workspace/project \ --json \ -- bash
The JSON result has exactly an executable and argv boundary (plus contractVersion: 1): the executable is docker, and argv begins with exec, -it, and -w. Pass that data to the separate terminal-opener skill when it is installed. This Docker harness deliberately does not import a terminal adapter, interpolate a shell command, or manage a host GUI process. Until then, open the same PTY in the current host terminal directly:
bashdocker exec -it -w /workspace/project ecc-plugin-shell bash
Exit the shell without stopping the detached container. Reconnect with the same docker exec -it command. When finished, remove the exact named container and its Compose project resources:
bashdocker rm --force ecc-plugin-shell docker compose -p ecc-plugin-session \ -f docker/plugin-setup/compose.yaml \ down --remove-orphans
Host credentials are absent by default and credential directories are never mounted. The default service also has no network access. When an authenticated provider session genuinely needs a network, build real-cli first and then opt in visibly with docker compose --profile networked run real-cli-networked shell. Prefer authenticating inside that disposable session. If a CI run must inherit a host environment credential, make that opt-in at invocation with an explicit Compose --env NAME flag, understand that the value is inspectable and can be exfiltrated for the container lifetime, and remove the exact named container immediately after.
Run the same focused suite natively on the host:
bashnpm run test:plugin-setup-platform
Inspect the produced identity and environment before trusting the image:
bashdocker image inspect ecc-plugin-setup:debian ecc-plugin-setup:ubuntu
Clean each named test project without deleting unrelated volumes or images:
bashdocker compose -p ecc-plugin-debian-test \ -f docker/plugin-setup/compose.yaml down --remove-orphans docker compose -p ecc-plugin-ubuntu-test \ -f docker/plugin-setup/compose.yaml down --remove-orphans
node_modules
.git
.env
.env.*
dist
coverage
*.log
.next
.cache
docker-compose*.yml
Dockerfile*
README.md
tests/bash# View logs docker compose logs -f app # Follow app logs docker compose logs --tail=50 db # Last 50 lines from db # Execute commands in running container docker compose exec app sh # Shell into app docker compose exec db psql -U postgres # Connect to postgres # Inspect docker compose ps # Running services docker compose top # Processes in each container docker stats # Resource usage # Rebuild docker compose up --build # Rebuild images docker compose build --no-cache app # Force full rebuild # Clean up docker compose down # Stop and remove containers docker compose down -v # Also remove volumes (DESTRUCTIVE) docker system prune # Remove unused images/containers
bash# Check DNS resolution inside container docker compose exec app nslookup db # Check connectivity docker compose exec app wget -qO- http://api:3000/health # Inspect network docker network ls docker network inspect <project>_default
# BAD: Using docker compose in production without orchestration
# Use Kubernetes, ECS, or Docker Swarm for production multi-container workloads
# BAD: Storing data in containers without volumes
# Containers are ephemeral -- all data lost on restart without volumes
# BAD: Running as root
# Always create and use a non-root user
# BAD: Using :latest tag
# Pin to specific versions for reproducible builds
# BAD: One giant container with all services
# Separate concerns: one process per container
# BAD: Putting secrets in docker-compose.yml
# Use .env files (gitignored) or Docker secrets| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-11 | pass→pass | 10,805 | 2,646 | -76% | 1 | 1 | 0% | 1,947 | 4,373 | +125% | 0 | 0 | — |
case-01 | fail→pass | 14,881 | 10,649 | -28% | 1 | 1 | 0% | 2,967 | 6,174 | +108% | 0 | 0 | — |
case-02 | fail→pass | 14,411 | 13,918 | -3% | 1 | 1 | 0% | 2,845 | 6,542 | +130% | 0 | 0 | — |
case-03 | pass→pass | 12,321 | 10,354 | -16% | 1 | 1 | 0% | 2,338 | 5,874 | +151% | 0 | 0 | — |
case-04 | pass→pass | 7,268 | 4,138 | -43% | 1 | 1 | 0% | 1,456 | 4,598 | +216% | 0 | 0 | — |
case-05 | pass→pass | 8,322 | 7,430 | -11% | 1 | 1 | 0% | 1,484 | 5,306 | +258% | 0 | 0 | — |
case-06 | pass→pass | 4,564 | 3,336 | -27% | 1 | 1 | 0% | 870 | 4,432 | +409% | 0 | 0 | — |
case-07 | pass→pass | 11,210 | 7,849 | -30% | 1 | 1 | 0% | 2,075 | 5,548 | +167% | 0 | 0 | — |
case-08 | pass→pass | 11,927 | 10,254 | -14% | 1 | 1 | 0% | 2,142 | 5,739 | +168% | 0 | 0 | — |
case-09 | fail→pass | 7,633 | 1,971 | -74% | 1 | 1 | 0% | 1,229 | 4,194 | +241% | 0 | 0 | — |
case-10 | pass→pass | 3,179 | 1,902 | -40% | 1 | 1 | 0% | 551 | 4,196 | +662% | 0 | 0 | — |
case-24 | pass→pass | 8,232 | 10,628 | +29% | 1 | 1 | 0% | 2,105 | 6,563 | +212% | 0 | 0 | — |
case-12 | fail→pass | 13,840 | 5,474 | -60% | 1 | 1 | 0% | 2,403 | 4,374 | +82% | 0 | 0 | — |
case-13 | fail→pass | 8,433 | 1,811 | -79% | 1 | 1 | 0% | 1,314 | 4,175 | +218% | 0 | 0 | — |
case-14 | pass→pass | 11,387 | 8,855 | -22% | 1 | 1 | 0% | 1,967 | 5,550 | +182% | 0 | 0 | — |
case-15 | pass→pass | 6,869 | 5,018 | -27% | 1 | 1 | 0% | 1,233 | 4,657 | +278% | 0 | 0 | — |
case-16 | pass→pass | 6,271 | 3,242 | -48% | 1 | 1 | 0% | 1,145 | 4,485 | +292% | 0 | 0 | — |
case-17 | pass→pass | 8,311 | 4,666 | -44% | 1 | 1 | 0% | 1,449 | 4,742 | +227% | 0 | 0 | — |
case-18 | fail→pass | 2,772 | 2,733 | -1% | 1 | 1 | 0% | 481 | 4,323 | +799% | 0 | 0 | — |
case-19 | pass→pass | 10,387 | 1,889 | -82% | 1 | 1 | 0% | 1,765 | 4,218 | +139% | 0 | 0 | — |
case-20 | pass→pass | 12,599 | 5,763 | -54% | 1 | 1 | 0% | 2,342 | 5,052 | +116% | 0 | 0 | — |
case-21 | pass→pass | 9,310 | 6,711 | -28% | 1 | 1 | 0% | 1,641 | 5,241 | +219% | 0 | 0 | — |
case-22 | pass→pass | 12,535 | 5,409 | -57% | 1 | 1 | 0% | 1,972 | 4,684 | +138% | 0 | 0 | — |
case-23 | pass→pass | 8,262 | 10,231 | +24% | 1 | 1 | 0% | 1,982 | 6,120 | +209% | 0 | 0 | — |
case-25 | pass→pass | 7,779 | 9,827 | +26% | 1 | 1 | 0% | 1,787 | 6,029 | +237% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 25 cases were attempted. The headline lift of +24 percentage points is the difference between those two pass rates over the 25 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
| Model | Method | Date | Lift |
|---|---|---|---|
| gemini-3.6-flash | verified | 7/27/2026 | — |
Other measured skills in the registry, with their headline benchmark lift.