Dockerfile & .env Validator: How to Lint Your Config Files Online

Why You Should Lint Dockerfiles and .env Files

Most container security incidents trace back to a small set of avoidable mistakes: a base image tagged :latest that silently pulled a breaking upstream change, anENV API_KEY=... line baked into an image layer that anyone with docker history access can read, or a .env file accidentally pushed to a public repository. None of these require exotic exploits — they are configuration errors that a linter catches in seconds.

Manual review works when you write the file. It fails when a colleague adds a line three months later, when a template is copied from Stack Overflow, or when a CI pipeline runs an unreviewed branch. Automated linting catches the drift.

How to Validate a Dockerfile

1. Open the Dockerfile & .env Validator and select the Dockerfile tab.
2. Paste your Dockerfile content into the text area. The placeholder shows a typical example with several common mistakes already present.
3. Click Validate. All checks run instantly in your browser — your file content is never transmitted anywhere.
4. Review the results panel. Each check shows one of three outcomes: Error (blocking issue that should be fixed before shipping), Warning (best-practice violation worth addressing), or Pass (the check is satisfied).
5. Fix the flagged issues in your Dockerfile, paste the updated content, and re-validate to confirm the errors are resolved.

All 10 Dockerfile Checks

How to Validate a .env File

1. Select the .env File tab in the validator.
2. Paste your .env file content. Comments (lines starting with #) and blank lines are ignored.
3. Click Validate. Results appear immediately with the same Error / Warning / Pass format.
4. Each result explains exactly what the issue is and how to fix it — for example, which keys are duplicated or which values contain an unquoted #.

All 6 .env File Checks

Advanced Workflows

What to fix first

Prioritise errors before warnings. The two Dockerfile errors — a missing FROM and secrets in ENV/ARG — are the highest-risk issues. A missing FROM prevents the build from running at all; a secret in ENV/ARG is invisible risk that persists in image history even after the value is removed in a later layer. For .env files, duplicate keys and format errors cause silent bugs that are hard to trace at runtime.

After clearing errors, work through warnings in impact order: pin your base image tag (reproducibility), add a USER instruction (security), then address size-related warnings (RUN consolidation, apt cache cleanup). Use a tool like Hash Generator to verify checksums when pinning base images by digest for maximum supply-chain security.

Integrating Dockerfile linting into CI

For automated pipeline validation, pair this browser tool with Hadolint — a command-line Dockerfile linter that covers the same best-practice checks. Add it to your GitHub Actions workflow:

- name: Lint Dockerfile
  uses: hadolint/hadolint-action@v3.1.0
  with:
    dockerfile: Dockerfile

The browser validator is ideal for quick checks during development; the CI step catches regressions before merge. Both cover the same core rules, so a Dockerfile that passes the validator will also pass Hadolint with default settings.

Pre-commit hook for .env files

The most effective way to prevent .env files from reaching version control is a pre-commit hook. Add this to .git/hooks/pre-commit:

#!/bin/sh
if git diff --cached --name-only | grep -qE '^\.env$|\.env\.(local|production|staging)'; then
  echo "ERROR: Attempting to commit a .env file. Remove it from staging."
  exit 1
fi

Use the validator alongside the hook — the hook prevents commits, but the validator finds issues in the file before you even reach the commit stage.

Validating .env files with the regex tester

If you need to validate that all values in a specific .env file match a required format (for example, all ports are numeric), the Regex Tester can test your validation pattern against sample values before you integrate it into a startup script or CI check.

Common Questions

Is my Dockerfile or .env file sent to a server?

No. All validation logic runs inside your browser using JavaScript. The text you paste is never transmitted, logged, or stored anywhere. You can disconnect from the internet after the page loads and the validator will still work correctly.

Why is :latest considered a problem?

The :latest tag always resolves to whatever the image maintainer published most recently. If you build the same Dockerfile on two different dates, you may get different base images — different OS versions, different library versions, different vulnerabilities. Pinning to a specific version like node:20.11-alpine3.19makes every build deterministic. When you want to upgrade, you do it deliberately by updating the tag, running your test suite, and merging the change — not accidentally because the upstream moved.

Should I ever commit a .env file?

Never commit a .env file that contains real values for secrets, passwords, or tokens. Add.env, .env.local, and .env.production to your.gitignore immediately. What you should commit is a .env.example file with all the required variable names and safe placeholder values. This documents the expected environment without exposing credentials.

What is the difference between ADD and COPY in a Dockerfile?

Both instructions copy files into the image, but ADD has two additional features that COPY lacks: it can fetch files from a URL and it automatically extracts local .tar.gz archives. These implicit behaviours make ADD unpredictable for simple file copies. The Docker documentation explicitly recommends using COPY for local files and only using ADD when you specifically need URL fetching or auto-extraction. Using COPY makes your intent clear and avoids surprises from unexpected tar extraction.

How do I pass secrets to a Docker container safely?

The three recommended approaches are: (1) pass secrets as environment variables at runtime with docker run -e SECRET=value — never in the Dockerfile; (2) use Docker secrets for Swarm or Kubernetes deployments, where secrets are mounted as files inside the container at /run/secrets/; (3) use a secrets manager like HashiCorp Vault or AWS Secrets Manager and have the application fetch its own secrets at startup. In all cases, the Dockerfile itself should contain no secret values.