Analyze & optimize your Dockerfile for best practices,
security, and smaller images
The analyzer looks for common security, build, and image-size concerns. Each rule below explains what it checks and what you can consider changing.
Detects an explicit USER root instruction. If the application does not need administrator privileges at runtime, create a dedicated user and switch to it with USER app.
When USER is missing, a separate analyzer check recommends adding a non-root user.
Finds a plain ADD instruction. COPY makes file copying explicit and is usually more predictable. Use ADD when you need its extra behavior, such as automatically extracting a local archive.
Looks for curl or wget in a RUN instruction. For build artifacts, consider downloading in a separate build stage and copying the result with COPY --from. Verify download sources and checksums.
This is a text-based heuristic, not a full shell-command analysis.
If a line containing apt-get install does not also contain cleanup for /var/lib/apt/lists, the analyzer suggests removing the package lists. Keeping update, install, and cleanup in one RUN helps avoid leaving them in an image layer.
When a Dockerfile has more than three RUN instructions, the analyzer suggests combining related commands. Each RUN creates an image layer; do not combine unrelated steps at the expense of readability and maintainability.
Flags any VOLUME instruction. It declares a mount point in the image and affects container behavior. Consider whether to declare it in the image or configure a volume or bind mount when starting the container.
Docker's VOLUME instruction is not deprecated; this is a recommendation from the analyzer, not a prohibition.
Looks for names such as PASSWORD, SECRET, TOKEN, or API_KEY in an ENV instruction. Do not put credentials in a Dockerfile; use your runtime platform's secret store or BuildKit secret mounts for build-time secrets.
The check examines variable names, not the value contents.
Finds :latest in a FROM instruction. A floating tag can refer to different image versions over time. Pin a specific tag, or use an image digest for stricter build reproducibility.
These eight checks are practical hints, not a complete security audit or Dockerfile validator. Review your project's context before applying any recommendation.
← Back to the analyzer