dockerfile-review

Dockerfile Review

STARTER_CHARACTER = 🐳

When starting, announce: "🐳 Using DOCKERFILE-REVIEW skill".

Process

1. Check if droast (dockerfile-roast) is available by running command -v droast
   • If available: run droast --no-roast --min-severity warning <Dockerfile> and use the output as a starting point
   • If not available: skip and continue with manual review
2. Read the Dockerfile (and .dockerignore if present)
3. Evaluate against each dimension below
4. Report findings grouped by severity: critical (security risks), major (significant size/performance impact), minor (incremental improvements)
5. For each finding: state what's wrong, why it matters, and suggest a fix direction
6. If the Dockerfile is solid, say so — don't invent issues

Review Dimensions

1. Layer Cache Ordering

Dependency files (package.json, requirements.txt, go.mod) must be copied and installed BEFORE application source code. Violations cause full dependency reinstalls on every code change.

Anti-pattern: COPY . . followed by RUN pip install or RUN npm ci. The entire dependency layer rebuilds on any source change.

Impact: builds that should take seconds take minutes. With frequent builds, this compounds to hours per week.

2. Base Image Selection

Three tiers exist: full (includes compilers, tools), slim (minimal OS, basic tooling), distroless (application only, no shell).

Anti-patterns:

• Using full images in production (node:20 is ~950MB vs node:20-slim at ~220MB)
• Using distroless when debugging access is needed
• Not considering slim as the default production choice

Alpine warning: Alpine uses musl libc instead of glibc. For Python, Node, and other runtimes with native extensions, this means rebuilding native deps from source (slower builds) or silent performance regressions. Prefer -slim (Debian-based) for these workloads — similar size savings, zero compatibility issues. Alpine remains a good choice for Go binaries and static builds where libc doesn't matter.