
Docker Patterns
- 1.5k installs
- 238k repo stars
- Updated August 5, 2026
- affaan-m/ecc
This is a copy of docker-patterns by affaan-m - installs and ranking accrue to the original listing.
docker-patterns is an agent skill that provides battle-tested Docker and Docker Compose patterns for developers who need secure, fast local development and multi-service container orchestration.
About
docker-patterns is an ECC agent skill cataloging Docker and Docker Compose best practices for containerized development. It guides developers through local Compose setups, multi-container architectures, networking and volume strategies, and Dockerfile reviews for image size and security. Reach for docker-patterns when migrating from bare-metal local dev to containers, troubleshooting service discovery or persistent storage, or standardizing repeatable dev environments across a team. The skill emphasizes practical patterns over theory: compose file structure, inter-service networking, volume mounts, and secure base-image choices. It suits backend and full-stack engineers standing up dependent services like databases, queues, and APIs behind a single docker compose up workflow.
- Ready-to-use docker-compose.yml templates for web app stacks with hot-reload and healthy service dependencies
- Multi-stage Dockerfile patterns that minimize image size and separate dev vs production layers
- Volume strategies including bind mounts, anonymous volumes, and named volumes for optimal local development
- Container networking, security, and troubleshooting patterns for multi-container architectures
- Migration checklist from local dev environments to fully containerized workflows
Docker Patterns by the numbers
- 1,528 all-time installs (skills.sh)
- +100 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Security screen: HIGH risk (skills.sh audit)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/affaan-m/ecc --skill docker-patternsAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.5k |
|---|---|
| repo stars | ★ 238k |
| Security audit | 2 / 3 scanners passed |
| Last updated | August 5, 2026 |
| Repository | affaan-m/ecc ↗ |
How do you structure Docker Compose for local dev?
Get battle-tested Docker and Docker Compose patterns that speed up local development, multi-service orchestration, and secure containerization.
Who is it for?
Backend and full-stack developers containerizing multi-service apps who need secure Compose patterns for repeatable local environments.
Skip if: Teams needing Kubernetes production manifests, managed cloud PaaS deployment guides, or Windows-only container edge cases.
When should I use this skill?
A developer sets up Docker Compose, reviews a Dockerfile, debugs container networking or volumes, or designs a multi-container local stack.
What you get
Docker Compose files, hardened Dockerfiles, networking and volume configurations, and reviewed multi-container architecture patterns.
- docker-compose.yml
- Dockerfile
- Networking and volume configuration guidance
Files
Docker Patterns
Docker and Docker Compose best practices for containerized development.
When to Activate
- Setting up Docker Compose for local development
- Designing multi-container architectures
- Troubleshooting container networking or volume issues
- Reviewing Dockerfiles for security and size
- Migrating from local dev to containerized workflow
Docker Compose for Local Development
Standard Web App Stack
# 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:Development vs Production 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"]Override Files
# 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# Development (auto-loads override)
docker compose up
# Production
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -dNetworking
Service Discovery
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 containerCustom Networks
services:
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:Exposing Only What's Needed
services:
db:
ports:
- "127.0.0.1:5432:5432" # Only accessible from host, not network
# Omit ports entirely in production -- accessible only within Docker networkVolume Strategies
volumes:
# 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_modulesCommon Patterns
services:
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 scriptsContainer Security
Dockerfile Hardening
# 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 layersCompose Security
services:
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 < 1024Secret Management
# 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.dockerignore
node_modules
.git
.env
.env.*
dist
coverage
*.log
.next
.cache
docker-compose*.yml
Dockerfile*
README.md
tests/Debugging
Common Commands
# 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/containersDebugging Network Issues
# 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>_defaultAnti-Patterns
# 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 secretsWhen to Use This Skill
- Setting up Docker Compose for local development
- Designing multi-container architectures
- Troubleshooting container issues
- Reviewing Dockerfiles for security
- Implementing container best practices
Related skills
How it compares
Choose docker-patterns for opinionated Compose and Dockerfile patterns during development setup, not production Kubernetes or cloud-specific IaC modules.
FAQ
When should developers use docker-patterns?
Developers should use docker-patterns when setting up Docker Compose for local development, designing multi-container architectures, troubleshooting networking or volume issues, or reviewing Dockerfiles for security and image size.
Does docker-patterns cover Docker Compose?
Yes. docker-patterns focuses on Docker and Docker Compose patterns including local development stacks, service orchestration, networking, volumes, and secure Dockerfile conventions.
Is Docker Patterns safe to install?
skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.