Dockerfile & .env Validator — Free Online Linting Tool
Paste a Dockerfile or .env file and get instant feedback on errors, security issues, and best practices. No upload, no signup — runs entirely in your browser.
Paste a Dockerfile above and click Validate to see the results.
How the Dockerfile & .env Validator Works
- 1Choose the Dockerfile or .env File tab depending on what you want to validate.
- 2Paste your file content into the text area. The placeholder shows a typical example with several common mistakes.
- 3Click Validate. The tool runs all checks instantly in your browser — your content is never transmitted anywhere.
- 4Review the results panel. Errors are blocking issues, warnings are best-practice violations, and passes confirm what is already correct.
Dockerfile Best Practices the Validator Checks
The Dockerfile validator covers the issues most commonly introduced in production containers. Pinning base image tags prevents non-reproducible builds. Adding a USER instruction reduces the blast radius if the container is compromised. Consolidating RUN commands reduces image layers and build time. Avoiding secrets in ENV and ARGprevents credentials from being baked into image history. Each check includes a specific explanation and suggested fix so you can resolve issues immediately.
Tips for Secure and Efficient Docker Configurations
Always pin base image versions
Replace FROM node:latest with FROM node:20.11-alpine3.19. Pinned tags make builds reproducible and prevent silent upstream changes from breaking your container.
Chain RUN commands to reduce layers
Combine related instructions: RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*. This reduces image size and keeps the cache invalidation surface small.
Use a non-root USER
Add RUN addgroup -S app && adduser -S app -G app and USER app before your CMD or ENTRYPOINT. Running as root gives unnecessary privilege inside the container.
Never commit .env files with real secrets
Add .env to .gitignore immediately. Maintain a .env.example with placeholder values so teammates know which variables to set.
Quote .env values containing special characters
If a value contains #, spaces, or shell-special characters, wrap it in double quotes: DESCRIPTION="Hello, world #1". This prevents the value being silently truncated.
Add a HEALTHCHECK to every long-running service
A HEALTHCHECK CMD curl -f http://localhost:3000/health || exit 1 lets Docker Swarm and Kubernetes detect and replace unhealthy container instances automatically.
Frequently Asked Questions
What does the Dockerfile validator check?
The Dockerfile validator runs 10 checks: whether a FROM instruction is present, whether the base image tag is pinned (not :latest), whether a USER instruction prevents running as root, whether ADD is misused instead of COPY, whether consecutive RUN commands could be consolidated, whether EXPOSE and HEALTHCHECK are present, whether ENV or ARG contains potential secrets, and whether apt-get installs use --no-install-recommends and clean up the package cache.
What does the .env validator check?
The .env validator checks six things: whether every content line follows the KEY=VALUE format, whether key names contain spaces (invalid), whether duplicate keys exist, whether any key has an empty value, whether values contain unquoted # characters that may be misread as inline comments, and whether any key names suggest the presence of credentials, tokens, or secrets.
Is my Dockerfile or .env file sent to a server?
No. All validation runs entirely inside your browser using JavaScript. Your file content is never uploaded, transmitted, or logged anywhere. You can disconnect from the internet after the page loads and the tool will work correctly.
Why is using :latest a problem in Dockerfiles?
The :latest tag is not a fixed version — it resolves to whatever the image maintainer pushes as latest at any given time. If you build the same Dockerfile on two different days, you may get different base images, causing non-reproducible builds. Pinning to a specific version like node:20.11-alpine3.19 ensures every build uses the exact same image.
Why should I not put secrets in ENV or ARG?
Secrets added via ENV or ARG are baked into the image layer and are visible to anyone who can run docker inspect or docker history on the image. If the image is pushed to a registry, the secrets are exposed. Use Docker secrets, runtime environment variables (passed at docker run time), or a secrets manager like HashiCorp Vault instead.
Should I commit my .env file to version control?
No. .env files typically contain real secrets (database passwords, API keys, tokens) and should be added to .gitignore to prevent accidental commits. Instead, maintain a .env.example file in the repository with all the required variable names but placeholder values, so developers know which variables to configure.
What is the difference between ADD and COPY in a Dockerfile?
Both copy files into the image, but ADD has two extra features: it can fetch files from URLs and it automatically extracts local .tar.gz archives. These implicit behaviours make ADD surprising for simple file copies. The Docker best practice is to use COPY for local files (its behaviour is explicit and predictable) and only use ADD when you specifically need URL fetching or auto-extraction.