Docker Compose Validator

Inspect Compose YAML structure, local cross-references, interpolation clues, named resources, and host-facing settings before checking the resolved project with Docker Compose.

Docker Compose YAML

Paste one Compose file. The text is read as written; sibling overrides, includes, env files, and shell variables are not loaded.

0 lines

Compose Inspection

Errors are structural. Warnings need context. Review notes flag settings that can materially reduce container isolation.

Compose syntax, structural findings, references, interpolation notes, and review items will appear here.

Local file inspection only

YAML parsing stays in your browser and no Compose-validation API receives the pasted file. Shell variables, .env files, includes, overrides, images, build context, the Docker Engine, and the host filesystem are not read. Site-wide analytics or advertising scripts, if enabled, are separate from this inspection.

Valid YAML Can Still Be a Broken Compose File

YAML parsing answers only the first question: can the text be turned into data? Docker Compose then expects an application model built around services, networks, volumes, configs, secrets, profiles, interpolation, and implementation rules. A file can therefore be perfect YAML while still referencing a missing service, using the wrong data shape for a field, or resolving differently once environment variables and override files are applied.

A local structural pass can catch relationships that plain YAML parsing cannot see, but the final application model still belongs to Docker Compose. The current Compose Specification is documented in the Compose file reference.

Follow One Service Through the Model

services:
  web:
    image: nginx:alpine
    depends_on:
      - api
    networks:
      - frontend
    volumes:
      - app-data:/usr/share/nginx/html

volumes:
  app-data:

networks:
  frontend:

The web service is not isolated from the rest of the file. Its depends_on value should name another service, frontend should exist as a network in the resolved Compose model, and app-data should be a declared named volume unless another Compose file supplies it. Those cross-references are exactly the kind of mistake plain YAML parsing cannot see.

Why Missing References Are Warnings Instead of Automatic Failures

Modern Compose projects can be assembled from multiple files, includes, extends relationships, profiles, and command-line overrides. A network or service that looks missing in one pasted file can legitimately appear in the final resolved model.

Unresolved local references are therefore warnings rather than automatic failures. If the project really is contained in one file, they are strong signals. In a modular project, inspect the resolved model before deciding that a reference is broken. Docker documents howinclude copies resources into the application model.

The version Field No Longer Selects a Compose Schema

Older Compose examples commonly begin with version: "3.8" or a similar value. In the current Compose Specification that top-level field is obsolete and kept only for backward compatibility. Docker Compose validates against its current implemented schema rather than switching behavior according to the version text.

Keeping version is not normally a fatal problem, so it is reported as a warning instead of an error. Docker describes the field as obsolete and informational in its version and name documentation.

Interpolation Can Change the File You Think You Are Validating

Compose supports expressions such as ${TAG}, ${PORT:-8080}, and required-variable forms. The final value can depend on shell variables, an env file, project location, CLI flags, and interpolation precedence. Compose applies interpolation before some merge behavior, so validating only the literal YAML cannot tell you the final image tag, path, port, or other substituted value.

Interpolation tokens are counted without treating $$ as a variable reference, because Compose uses a double dollar sign for a literal dollar. Values are deliberately left unresolved rather than asking for shell or env-file secrets. Docker's interpolation rules cover defaults, required forms, nesting, and escaping.

Some Compose Settings Deserve a Security Review, Not Just Schema Validation

A Compose file can be syntactically valid and still grant a container unusually broad access to the host. Those settings are called attention to a small set of high-impact examples such as privileged: true, host networking or namespaces, cap_add: [ALL], and Docker socket mounts.

These settings are not automatically malicious—monitoring agents, development tools, and infrastructure workloads sometimes need them. The point is to make them visible before running an unfamiliar Compose project.

Short Volume Syntax Has More Than One Meaning

In ./data:/app/data, the source is a host path. In app-data:/app/data, the source is a named volume. In /app/data, the entry can describe an anonymous volume. Only the named-volume case is resolved against the top-level volumes mapping; bind paths do not need a top-level declaration.

Variable interpolation and platform-specific path syntax make this distinction tricky, which is another reason the Docker CLI remains the final authority.

Close the Gap With the Resolved Compose Model

Before deployment, run the same files and environment through docker compose config. Docker documents that command as parsing, resolving, merging, and rendering the actual application model. If only validation is needed, docker compose config -qperforms the configuration check quietly. The docker compose config reference covers the same resolution boundary.