Dockerfile and Compose Linter

Check Dockerfile or Compose text with a bounded static rule set and line references for review.

Inputs stay on your device No sign-up Free to use
How this works

The tool runs in this browser. Your file or text is not uploaded to UseFreeTools. Check this tool's limits for anything it may save on your device.

Privacy details

Check configuration controls

Showing an example. Edit to see your own.

Static Dockerfile rules inspect FROM digests, secret-like ARG/ENV names, stage USER choices, and separate apt/apk update/install RUN layers. Up to 100,000 characters and 5,000 lines.

Bounded JSON-compatible YAML parsing checks duplicate keys, top-level and service keys, image digests, privileged mode and host networking. Up to 100,000 characters, 5,000 lines, 40 levels and 12 aliases.

Processed in your browser. Your inputs stay on this device.

How to use Dockerfile and Compose Linter

  1. Paste a Dockerfile, Compose configuration or both in their labelled inputs.
  2. Run the checks without building an image or starting containers.
  3. Review each reported line and the rule that produced the observation.
  4. Use the actual Docker tools and your deployment requirements to validate a revised configuration.

Example: Dockerfile and Compose Linter

Review synthetic container configuration.

You add
Dockerfile: FROM node:22-alpine, ENV API_TOKEN=example-only and USER 10001 on separate lines. Compose: a web service with image app:latest, privileged: true and network_mode: host.
You get
The static report identifies moving image references, the secret-like ENV name, privileged mode and host networking. It does not repeat example-only as a secret value or run containers.

Supported inputs and limits

Each document is limited to 100,000 characters and 5,000 lines. UFT-DockerRules 1.0 and UFT-ComposeKeys 1.0 report up to 200 findings and state how many were omitted. Compose YAML uses js-yaml 5.4.1 JSON_SCHEMA with duplicate keys refused, a maximum depth of 40, 12 alias references and 20,000 visited nodes. The rules inspect immutable image digests, selected Dockerfile instructions, secret-like variable names and selected Compose keys, privilege and network settings. It does not build images, resolve variables or files, run containers, validate the complete engine grammar or certify security.

Where your input is processed

This tool processes your input in this browser. Your text and files are not uploaded to UseFreeTools. Check this tool's limits for anything it may save on your device.

Static review and engine validation serve different tasks

Line checks can point out a moving image reference or a setting worth revisiting. They cannot inspect an included file or test a container's runtime behavior. Review the observations alongside the Dockerfile and Compose specifications, then validate the actual configuration in its intended environment.

Questions about Dockerfile and Compose Linter

Does a clean report mean the configuration will run?

No. The page checks only its listed text rules. It does not resolve files, environment values, images, networks or the target engine's complete configuration grammar.

Why is an image tag reported?

A tag can point to a different build later, including a tag that names a version. The rule looks for an immutable sha256 digest. It does not verify the image's contents or choose a version for you.

Does the page display secret values?

The report identifies a secret-like variable name or its line without repeating its value. It cannot recognise every possible secret, so remove live credentials before preparing a sample.

Are privileged settings always an error?

They are configuration observations that need context. A static page cannot establish the permissions or isolation your particular workload requires.

Project manager: Tony Hines · Content updated 1 October 2026 · Report a problem