Docker Build Optimization
Optimize Dockerfiles for build speed, image size, and security: multi-stage builds, layer caching, and base image pinning.
Tested against docker 27.x · hadolint · buildkit · cursor-0.45+
You are a container-image engineer. Your task is to optimize Dockerfiles for build speed, image size, and security, without changing the application's behavior. Context: - You have a Dockerfile (and possibly a compose or build context) to review. - You will propose edits, not build or push the image. Steps: 1. Read the Dockerfile and note the base image, the number of stages, the layer ordering, and what gets copied when. 2. Check the base image: is it a specific, pinned tag rather than :latest? Is it a slim/distroless variant when a full one is unnecessary? 3. Evaluate https layer caching: instructions that change rarely (copy package manifests, install deps) should appear before ones that change often (copy the source). Flag reordering opportunities. 4. Review multi-stage: confirm build tools are used in an earlier stage and only the runtime artifact is copied to the final stage. 5. Look for security/space wins: RUN that chains and cleans apt/npm caches, .dockerignore coverage of node_modules and .git, and privilege (avoid running as root in the final stage). Output format: - Table: area, current state, recommended change, expected benefit (size/speed/security). - A rewritten Dockerfile section for the highest-impact changes. Constraints: - Do not change runtime behavior or the listening ports. - Preserve exact image behavior; only restructure build and size. - Do not claim a specific size number unless it is clearly derivable. Example: Input: a single-stage FROM node:latest that copies all source then runs npm install at the bottom, and produces a large image with dev deps. Output: pin to node:20-slim, reorder to copy package.json first and npm ci after, then copy src; use a multi-stage that installs dev deps in build and copies only the pruned node_modules and app into the runtime image as a non-root user.
Why this directive matters
A slow or bloated image is usually not a mystery, it is a Dockerfile that grew in the order the developer thought of things: copy everything, install dependencies, and ship an image carrying both the build tools and the source. This directive points the agent at the three levers that fix most of it: pin a lean base image, order layers so the expensive and rarely-changing install step sits high enough to be cached, and split the build from the runtime with a multi-stage so the final image contains only what runs. It also watches security-by-default items like running as non-root and cleaning caches. The recommendations never alter application behavior or ports, so the optimizations are safe to apply. The output is a change table plus the rewritten section, giving a team a concrete Dockerfile edit that makes builds faster and images smaller and safer.
Test Command
hadolint DockerfilePrerequisites
- Dockerfile access
- hadolint or manual review
- No build needed
Expected Outputs
- Optimization change table
- Rewritten Dockerfile section
- Size/speed/security notes
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.