Analyze Dockerfiles for base images, build stages, instructions, ports, users, environment variables, caching opportunities, and common containerization issues.
Inspect Dockerfile instructions, base images, build stages, ports, users, and common containerization issues.
Your support helps us build more tools and improve the ones you already use.
More tools you may find useful.
Analyze Docker Compose files for services, images, builds, ports, volumes, networks, dependencies, environment variables, and common container configuration issues.
Analyze Kubernetes manifests to inspect resources, workloads, replicas, containers, images, labels, selectors, references, and common configuration issues.
Analyze AWS IAM policies for wildcard permissions, overly broad access, potentially risky actions, and common policy configuration issues.
Validate .env files, detect duplicate variables, check variable names and identify common environment configuration issues.
Dockerfile Analyzer is a browser-based static analysis tool for reviewing Dockerfiles before building container images. It inspects Dockerfile instructions, base images, build stages, runtime configuration, exposed ports, and common containerization practices without executing Docker commands.
A Dockerfile is a text file that defines the instructions Docker uses to build a container image. It commonly specifies a base image, working directory, application files, dependencies, environment settings, exposed ports, and the command used to start the container.
Because Dockerfiles directly influence image contents and runtime behavior, reviewing them before a build can help identify reproducibility, security, maintainability, and container lifecycle concerns.
A base image without an explicit version can change when the image is rebuilt, which may make builds less reproducible. Explicit version tags provide more predictable behavior, while image digests can provide stronger immutability.
The analyzer reports unpinned base images as recommendations rather than automatically treating them as insecure. The appropriate level of pinning depends on the project's release, security, and maintenance requirements.
Multi-stage builds use multiple FROM instructions to separate build-time dependencies from the final runtime image. This can reduce the size of production images and prevent unnecessary build tools from being included in the final container.
Dockerfile Analyzer detects multiple FROM instructions and reports them as a multi-stage build pattern. It does not attempt to determine whether every stage is optimally structured.
Dockerfile analysis can identify patterns that deserve security review, but static analysis cannot prove that a container is secure. The actual security posture also depends on the base image, application dependencies, runtime configuration, container privileges, orchestration environment, and deployment process.
Secrets should not be embedded directly in Dockerfile instructions. Build secrets, runtime secret management, and platform-specific mechanisms should be considered when sensitive values are required.
Dockerfile Analyzer performs static analysis in the browser. It does not build the Docker image, execute Docker commands, or require access to a Docker daemon.
Do not paste passwords, API keys, access tokens, private registry credentials, or other sensitive information into online tools unless you understand the privacy implications.
This tool performs pattern-based static analysis and does not build or execute the Dockerfile. It cannot determine whether an image successfully builds, whether dependencies are secure, or whether the resulting container is correctly configured in its target environment.
Some warnings are recommendations rather than errors. A Dockerfile may intentionally use a particular pattern depending on the application, operating system, deployment platform, or operational requirements.
No. The analyzer performs static analysis only. It does not execute Docker commands, build images, or access a Docker daemon.
The analyzer reports a base image when it does not use an explicit version tag or digest. Using a predictable version can improve build reproducibility.
No. It can be valid for some development workflows, but it can make builds less predictable because the referenced image may change over time.
Without a USER instruction, a container may run as root depending on the base image and configuration. Running applications as a dedicated non-root user can reduce the impact of certain container compromises.
COPY is generally preferred for straightforward local file copying. ADD has additional features, such as archive extraction, so it can still be appropriate for specific use cases.
It can identify ENV and ARG instructions that deserve review, but it cannot reliably determine whether their values contain secrets. Avoid placing credentials directly in Dockerfiles.
Multi-stage builds can separate build dependencies from the production runtime image, often resulting in smaller and cleaner final images.
No. Warnings are recommendations based on common Dockerfile practices. A warning does not necessarily mean that the Dockerfile is invalid or insecure.