Install
$ agentstack add skill-xcrrr-claude-skills-docker-expert Open-source listing, not yet scanned by AgentStack. Follow the source repository for install instructions.
Security review
⚠ Flagged1 finding(s); flagged for manual review. · v0.1.0 How review works →
- • Prompt-injection patterns
- • Secret / credential exfiltration
- • Dangerous shell & filesystem operations
- • Untrusted network calls
- • Known-malicious package signatures
- high Destructive filesystem operation.
What it can access
- ● Network access Used
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ● Environment & secrets Used
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Docker Expert
Overview
The Docker Expert skill produces optimized, production-ready Dockerfiles and Docker Compose configurations for any application stack. It applies container best practices: minimal base images (Alpine, Distroless, slim variants), multi-stage builds to minimize final image size, non-root user execution for security, strategic layer ordering to maximize cache reuse, .dockerignore files to exclude unnecessary build context, and health check definitions for orchestrator integration. The skill handles single-service containerization and multi-service local development environments with Docker Compose, including networking, volumes, secrets, and environment variable management.
When to Use
- Writing a new Dockerfile for any application (Node.js, Python, Java, Go, Ruby, etc.)
- Reducing Docker image size with multi-stage builds and minimal base images
- Applying container security hardening (non-root user, read-only filesystem, dropped capabilities)
- Configuring a
docker-compose.ymlfor local development with databases, caches, and app services - Writing
.dockerignorefiles to reduce build context size and prevent secret leakage - Adding
HEALTHCHECKinstructions for container health monitoring - Troubleshooting slow builds, large images, or container startup failures
- Converting a non-containerized app to run in Docker for the first time
When NOT to Use
- Writing Kubernetes manifests or Helm charts (use the kubernetes-helper skill)
- Provisioning managed container services (AWS ECS, Google Cloud Run, Azure Container Apps)
- Designing CI/CD pipelines that build and push Docker images (use the ci-cd-helper skill)
- Setting up container registries (ECR, GCR, GHCR) from scratch
- Orchestrating containers at scale in production (use Kubernetes)
Quick Reference
| Task | Approach | |------|----------| | Minimize image size | Use multi-stage build; copy only compiled artifacts to a minimal final stage (Alpine/Distroless) | | Run as non-root | Add RUN addgroup -S app && adduser -S app -G app then USER app before CMD | | Maximize layer cache | Order instructions: COPY lockfile → RUN install → COPY source code | | Exclude build context files | Create .dockerignore listing node_modules/, .git/, *.log, .env, dist/ | | Health check | HEALTHCHECK --interval=30s --timeout=5s --retries=3 CMD curl -f http://localhost:8080/health | | Multi-service dev env | Use docker-compose.yml with depends_on:, named volumes, and a shared network | | Pin base image versions | Use node:20.14.0-alpine3.19 not node:latest for reproducible builds |
Instructions
- Identify the application stack and runtime — Confirm the language, framework, package manager, and build output format (e.g., "Node.js 20 with npm, Express app, no build step" or "Python 3.11 with Poetry, FastAPI, no compiled artifacts"). This determines the appropriate base image family.
- Choose the base image strategy — Select the smallest suitable base image: use language-specific Alpine or slim variants for interpreted languages (e.g.,
python:3.11-slim,node:20-alpine). For compiled languages (Go, Rust), use a full build image for the build stage andgcr.io/distroless/staticorscratchfor the final stage.
- Design a multi-stage build — Use at minimum a
builderstage (full SDK image for installing dependencies and compiling) and arunnerstage (minimal image for running the app). Copy only production artifacts from builder to runner:COPY --from=builder /app/dist ./dist.
- Optimize layer caching — Order
COPYandRUNinstructions from least-frequently-changed to most-frequently-changed. Always copy the dependency manifest first, run the install, then copy source code. This ensures a dependency cache hit on every commit that only changes source code.
- Harden for security — Create a dedicated non-root user and group; switch to it with
USERbefore theCMDorENTRYPOINT. Avoid running asroot. Consider adding--cap-drop=ALLand--read-onlyat runtime for sensitive services.
- Write a
.dockerignorefile — Exclude:.git/,node_modules/(or language equivalent),*.log,.env*,dist/,coverage/, IDE config files (.vscode/,.idea/), and any files with secrets. A small build context speeds up builds and prevents accidental secret inclusion.
- Define environment variables correctly — Use
ENVfor runtime configuration defaults that are safe to bake into the image. UseARGfor build-time variables that should not persist in the final image. Never useENVorARGfor secrets — pass secrets at runtime via--env-fileor Docker secrets.
- Add a
HEALTHCHECKinstruction — Define a health check command so Docker and orchestrators can detect when the container is ready and unhealthy. Use the application's own health endpoint or a lightweight check (wget -qO- http://localhost:PORT/health).
- Configure Docker Compose for multi-service environments — Define services, expose ports, configure named volumes for persistent data, and link services via a shared named network. Use
depends_on: condition: service_healthyto enforce startup ordering.
- Validate and document the setup — Provide the build command (
docker build -t myapp:latest .), run command (docker run -p 3000:3000 myapp:latest), and Compose command (docker compose up -d). Note any required environment variables and how to supply them securely.
Examples
Example 1: Production-Optimized Node.js Dockerfile
Input: "Write a production Dockerfile for a Node.js 20 Express app using npm. The app runs on port 3000. Include multi-stage build, non-root user, health check, and .dockerignore."
Output:
# .dockerignore
node_modules/
npm-debug.log*
.git/
.gitignore
.env*
dist/
coverage/
.nyc_output/
*.md
.vscode/
.idea/
# Dockerfile
# ── Stage 1: Install dependencies ────────────────────────────────────────────
FROM node:20-alpine3.19 AS deps
WORKDIR /app
# Copy manifests first to leverage layer cache — reinstall only when deps change
COPY package.json package-lock.json ./
RUN npm ci --omit=dev # Install production deps only; --omit=dev skips devDependencies
# ── Stage 2: Build (if applicable — e.g., TypeScript, webpack) ───────────────
FROM node:20-alpine3.19 AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci # Install ALL deps (including devDependencies) for build step
COPY . .
RUN npm run build # Compiles TS, runs webpack, etc. Remove if no build step.
# ── Stage 3: Production runtime ──────────────────────────────────────────────
FROM node:20-alpine3.19 AS runner
# Create a dedicated non-root user for security
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
# Copy production node_modules from deps stage
COPY --from=deps /app/node_modules ./node_modules
# Copy built application from builder stage
COPY --from=builder /app/dist ./dist
COPY package.json ./
# Switch to non-root user before starting the app
USER appuser
EXPOSE 3000
# Health check — orchestrators use this to know when the app is ready
HEALTHCHECK --interval=30s --timeout=5s --start-period=15s --retries=3 \
CMD wget -qO- http://localhost:3000/health || exit 1
# Use exec form (array) to ensure signals (SIGTERM) reach the Node process
CMD ["node", "dist/server.js"]
# Build
docker build -t myapp:latest .
# Run (pass secrets via --env-file, never bake them into the image)
docker run -d \
-p 3000:3000 \
--env-file .env.production \
--read-only \
--tmpfs /tmp \
--name myapp \
myapp:latest
Result: Final image is ~180 MB (vs ~1.1 GB with a full Node image and no multi-stage build). Runs as non-root appuser. Health check enables Kubernetes/Docker Swarm readiness detection.
Example 2: Python Flask App with Docker Compose (App + Postgres + Redis)
Input: "Set up Docker Compose for a Python 3.11 Flask app (using pip and requirements.txt) with a Postgres 15 database and Redis 7 cache. The Flask app should hot-reload in development."
Output:
# Dockerfile (development — hot reload via Flask dev server)
FROM python:3.11-slim AS base
# Install system dependencies required by psycopg2 and other packages
RUN apt-get update && apt-get install -y --no-install-recommends \
gcc libpq-dev curl \
&& rm -rf /var/lib/apt/lists/*
# Create non-root user
RUN groupadd -r flaskuser && useradd -r -g flaskuser flaskuser
WORKDIR /app
# Install Python dependencies (cached layer — only reinstalls when requirements.txt changes)
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# Copy application source
COPY . .
RUN chown -R flaskuser:flaskuser /app
USER flaskuser
EXPOSE 5000
HEALTHCHECK --interval=20s --timeout=5s --start-period=10s --retries=3 \
CMD curl -f http://localhost:5000/health || exit 1
CMD ["flask", "run", "--host=0.0.0.0"]
# docker-compose.yml
version: '3.9'
services:
app:
build:
context: .
dockerfile: Dockerfile
container_name: flask-app
ports:
- "5000:5000"
environment:
FLASK_ENV: development
FLASK_APP: app:create_app
DATABASE_URL: postgresql://postgres:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}
REDIS_URL: redis://redis:6379/0
env_file:
- .env.development # Contains POSTGRES_PASSWORD, SECRET_KEY, etc.
volumes:
- .:/app # Mount source for hot-reload in development
depends_on:
db:
condition: service_healthy
redis:
condition: service_healthy
networks:
- backend
db:
image: postgres:15-alpine
container_name: flask-db
environment:
POSTGRES_DB: ${POSTGRES_DB:-myapp}
POSTGRES_USER: postgres
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- postgres_data:/var/lib/postgresql/data
- ./db/init.sql:/docker-entrypoint-initdb.d/init.sql:ro
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 5
networks:
- backend
redis:
image: redis:7-alpine
container_name: flask-redis
command: ["redis-server", "--save", "60", "1", "--loglevel", "warning"]
volumes:
- redis_data:/data
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 10s
timeout: 5s
retries: 3
networks:
- backend
volumes:
postgres_data:
redis_data:
networks:
backend:
driver: bridge
# Start all services
docker compose up -d
# View logs
docker compose logs -f app
# Run database migrations
docker compose exec app flask db upgrade
# Tear down (keep volumes)
docker compose down
# Tear down and delete all data volumes
docker compose down -v
Best Practices
- Always pin base image versions (
node:20.14.0-alpine3.19notnode:latest) for reproducible builds - Use multi-stage builds for every app that has a build step — the difference in final image size is dramatic
- Run containers as a non-root user in every environment, including development
- Copy dependency manifests before source code to maximize Docker layer cache utilization
- Always include a
.dockerignorefile — without it,node_modules/or.git/can be sent as build context - Use
HEALTHCHECKin every production Dockerfile so orchestrators can detect unhealthy containers - Prefer
CMDin exec form (["node", "server.js"]) over shell form (node server.js) so signals propagate correctly
Common Mistakes
- Using
COPY . .before installing dependencies — breaks layer caching; every source change triggers a full reinstall - Running containers as root (default if
USERis not set) — significant security vulnerability - Using
:latesttags for base images — leads to non-reproducible builds as upstream images update - Storing secrets in
ENVinstructions — they are visible indocker inspectand image layers - Not using
--no-cache-dirforpip install— wastes image space on cached wheel files - Installing development tools (curl, vim, git) in production images — increases attack surface and image size
- Forgetting to clean up apt/apk cache in the same
RUNlayer that installs packages
Tips & Tricks
- Use
docker image history myapp:latestto see each layer's size and identify what to optimize - Use
docker buildx build --platform linux/amd64,linux/arm64to build multi-architecture images for Apple Silicon and cloud compatibility - Use Docker's
--build-argwithARGto pass build-time configuration (e.g., environment name, version tag) without baking it intoENV - Use
docker compose watch(Compose v2.22+) for smarter file-watching hot reload that avoids volume mount pitfalls - Add
--squashor use BuildKit's--mount=type=cacheto further optimize image size and build speed - Use
docker scout cves myapp:latestto scan your built image for known CVEs before pushing - In multi-stage builds, name stages with
AS nameand reference them inCOPY --from=namefor clarity and build targeting
Related Skills
- [ci-cd-helper](../ci-cd-helper/SKILL.md)
- [kubernetes-helper](../kubernetes-helper/SKILL.md)
- [security-auditor](../security-auditor/SKILL.md)
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: xcrrr
- Source: xcrrr/claude-skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.