Tool Overview

This tool checks a Dockerfile for a set of common best-practice and correctness issues. It scans the text line by line and reports problems such as use of the latest tag, missing flags in apt-get install, use of ADD instead of COPY, and running as root. It does not parse full Dockerfile syntax or run Docker; it only applies built-in rules and shows suggestions so you can fix the file before building.

Bad or insecure Dockerfiles lead to large images, failed builds, or security risks. Finding these issues by hand is slow. This tool runs the checks as you edit and shows each finding with a short explanation and a suggested fix. A related operation involves validating Docker Compose files as part of a similar workflow.

It is for developers and operators who write or review Dockerfiles. You need basic knowledge of Docker and Dockerfile instructions. No account or sign-in is required. For adjacent tasks, validating Kubernetes YAML addresses a complementary step.

Background and How the Tool Works

A Dockerfile is a text file of instructions used to build a container image. Each line is usually one instruction (FROM, RUN, COPY, and so on). Some choices make images bigger, less reproducible, or less secure. For example, using the latest tag for a base image can change behavior over time; running apt-get install without the non-interactive flag can hang builds; running the container as root is a security risk. When working with related formats, validating Helm charts can be a useful part of the process.

This tool does not run the Docker build. It reads your Dockerfile as text and applies a fixed set of rules. It looks for patterns like FROM something:latest, apt-get install without -y, ADD for local files, RUN mkdir followed by cd, no USER instruction, consecutive RUN lines, and CMD with a port but no EXPOSE. For each match it adds a finding with a severity (error, warning, or info), a message, an explanation, and often a suggested replacement. You can filter findings by severity and apply suggestions one by one or copy a version of the file with all suggestions applied. In some workflows, validating JSON syntax is a relevant follow-up operation.

People struggle when the build fails or when they are unsure which practices to follow. The tool gives immediate feedback and concrete suggestions so you can fix issues before building. For related processing needs, validating XML structure handles a complementary task.

Key Features

• Single input: One editor for your Dockerfile. You paste or type the content. Input is limited to 50,000 characters. The tool does not upload files; you paste the content. A character count is shown so you can stay under the limit.
• Automatic validation: When you change the content, the tool runs the rules again and updates the list of findings. You do not need to click a button to validate.
• Built-in rules: The tool checks for: base image using the latest tag; apt-get install without the -y flag; apt-get install without cleaning the package cache; use of ADD instead of COPY for local files; RUN mkdir and cd that could be WORKDIR; no USER instruction (container runs as root); consecutive RUN commands that could be combined; CMD with a port but no EXPOSE. Each rule has a code, a message, an explanation, and often a suggested fix.
• Severity levels: Findings are error, warning, or info. Errors are things that often break or block builds (for example apt-get install without -y). Warnings are practices to avoid (latest tag, ADD, no non-root user). Info is optional improvement (cache cleanup, combine RUN, add EXPOSE). You can filter the list to show all findings or only errors, warnings, or info.
• Issue list: Each finding shows the rule code, line number, and message. You can expand a finding to see the full explanation, the original line, and the suggestion. An Apply Fix button replaces the original line (or appends at the end for the no-USER suggestion) with the suggestion in the editor.
• Copy clean version: A button builds a version of the file where every finding that has a suggestion is replaced by that suggestion, then copies that text to the clipboard. You can paste it into a new file or replace the editor content by hand. The tool does not change the editor content automatically when you copy.
• Sample Dockerfiles: You can load one of three samples (Node.js app, Python API, multi-stage build) into the editor. Use them to see how the tool reports issues and suggestions.
• AI Architectural Advisor: An optional button sends your Dockerfile to a backend service. You may get back a short summary, a security score out of 100, and a list of advanced suggestions (title and description). This feature may be unavailable or fail. The tool does not apply AI suggestions automatically; you read them and change the Dockerfile yourself.

Common Use Cases

You are writing a new Dockerfile and want to avoid common mistakes. You paste the content and fix any errors and warnings before the first build. You are reviewing someone else’s Dockerfile and use the tool to spot latest tags, root usage, and ADD. You have a working Dockerfile and want to shrink the image or improve security; you use the info-level suggestions (cache cleanup, combine RUN, EXPOSE) and the AI advisor if available. You use the samples to learn what the tool flags and how to fix it.

How to Use This Tool

1. Open the tool. You will see an editor on the left and an issues list on the right.
2. Paste your Dockerfile into the editor or click one of the sample buttons (Node.js App, Python API, Multi-stage Build) to load an example. Keep the content under 50,000 characters; the counter at the bottom shows the current length.
3. Validation runs automatically. Look at the issues list. Use the filter buttons (All, Errors, Warnings, Info) to show all findings or only one severity.
4. Click a finding to expand it. Read the explanation and the suggested fix. Click Apply Fix to replace the original line in the editor with the suggestion (or to append the suggestion at the end for the no-USER finding). Repeat for other findings as needed.
5. To get a version of the file with all suggestions applied, click Copy Clean Version. The tool builds that version and copies it to the clipboard. Paste it elsewhere or into the editor if you want to replace the whole content.
6. Optional: click Analyze with AI to send the Dockerfile to the AI advisor. Wait for the result. You may see a summary, a security score, and a list of advanced suggestions. Read them and edit the Dockerfile yourself; the tool does not apply AI suggestions automatically. If the request fails, fix issues using the built-in rules and suggestions.

Reference: Rules Checked

Tips, Limitations and Best Practices

Keep the Dockerfile under 50,000 characters and 10,000 lines so the tool can process it. Fix errors first (for example apt-get install -y), then address warnings (pin base image, use COPY, add USER), then consider info (cache cleanup, combine RUN, EXPOSE). The suggestion to replace :latest with :20.04 is generic; change it to the version that fits your base image (for example node:18, python:3.11).

The tool does not parse full Dockerfile syntax. It does not validate instruction arguments in detail or check that base images exist. It does not run Docker or build the image. For full syntax validation or multi-stage logic, use Docker build or other tools. The AI advisor is optional and may be unavailable; rely on the built-in rules for consistent feedback.

Do not paste secrets or credentials into the editor. The AI advisor sends the Dockerfile to a backend service; use it only for non-sensitive content.