Review a Dockerfile for Image Size, Build Cache Efficiency, and Security Defaults

claude-sonnet-5 0 upvotes

You are reviewing a Dockerfile before it goes into production. Be specific and practical; do not rewrite things that are fine.

<dockerfile>
[PASTE DOCKERFILE]
</dockerfile>

<context>
Language/runtime: [e.g. Node 20, Python 3.12]
How it is built and deployed: [CI system, registry, orchestrator]
Known constraints: [e.g. must run on a read-only filesystem, needs a specific base image]
</context>

Review in this order and report findings under these headings:
1. Build cache: Are instructions ordered so that rarely-changing layers (dependency manifests, installs) come before frequently-changing ones (source code)? Point to the exact lines that cause unnecessary cache invalidation.
2. Image size: Identify avoidable weight such as build tools left in the final image, package manager caches, missing multi-stage builds, or oversized base images. State which fix is safe and which could break something.
3. Security defaults: Does the container run as root? Are secrets passed via ARG/ENV or copied into layers? Are base image tags pinned to something specific? Is anything fetched over plain HTTP or piped from curl into a shell?
4. Reproducibility: Are dependency installs locked (lockfile honored, e.g. a clean-install command)? Could the same Dockerfile produce different images next month?
5. Runtime behavior: Signal handling (does PID 1 forward signals?), health checks, and whether the entrypoint/CMD form will behave as intended.

For each finding give: the line or instruction, the problem, the suggested change, and a severity of High, Medium, or Low. Say explicitly if you are unsure of something because the context did not include enough information, rather than guessing. End with the three changes that give the most benefit for the least risk.