Docker Compose Validator: Catch Structural Mistakes Before You Deploy
A typo in a service name referenced by depends_on, a missing image or build key, or a forgotten network declaration are all mistakes that docker compose up will only reveal at runtime. This validator parses your compose file's YAML structure and cross-checks every internal reference, so you catch these mistakes while reading the file, not after a failed deploy.
Same cross-reference logic applies to networks and volumes.
What This Validator Cross-Checks
Beyond basic YAML syntax, it verifies that every service actually has an image or a build key (Compose requires one), that depends_on entries reference real service names, and that a service's networks entries match something declared under the top-level networks key.
Why Image Tags Matter
An image reference without a tag (like nginx instead of nginx:1.27) implicitly pulls :latest, which can silently change between deployments — the same docker-compose.yml might pull a different image today than it did last month. This validator flags both untagged images and explicit :latest tags as reproducibility risks.
What This Tool Can't Check
It validates the YAML structure and internal consistency of your compose file, but it can't verify that a referenced image actually exists on a registry, that a build context path is valid on your filesystem, or that environment variables referenced elsewhere are actually set — those require the Docker CLI itself.
Practical Examples
Catching a Missing Service Definition
A typo in depends_on.
- 1.depends_on: [databse]
- 2.Error: Service "web" depends_on unknown service "databse"
- 3.Fix: correct the typo to "database"
Flagging an Unpinned Image
A common reproducibility issue.
- 1.image: redis
- 2.Warning: no tag — defaults to :latest
- 3.Fix: image: redis:7.2
What Gets Validated
- services key exists and is non-empty
- Each service has image or build
- depends_on references exist
- networks references exist
- Image tags — flags missing or :latest
Good Use Cases
- Reviewing a docker-compose.yml before opening a pull request
- Debugging why 'docker compose up' fails with a cryptic reference error
- Auditing a multi-service compose file for untagged images
- Learning docker-compose.yml structure with immediate feedback
Frequently Asked Questions
Does this replace 'docker compose config'?
No. The Docker CLI's own validation is authoritative and checks things this tool can't, like whether an image actually exists or whether build context paths resolve. This tool catches structural mistakes early, in your browser, before you even have Docker running.
Why does it flag :latest as a warning, not an error?
Using :latest is valid YAML and valid Compose syntax, but it's a well-known reproducibility risk — the exact image content can change between pulls. It's flagged as a warning so you're aware, not blocked.
How does it check depends_on references?
It collects every service name defined under the top-level 'services' key, then checks that every value listed in a service's depends_on (whether written as a list or a mapping) matches one of those names.
Does it validate build context paths or Dockerfile contents?
No — it only validates the docker-compose.yml file's own structure. It can't check whether a referenced build context directory or Dockerfile actually exists, since it has no access to your filesystem.
What YAML features aren't supported?
The parser handles the common subset used in real docker-compose files — mappings, sequences, quoted/plain scalars, comments — but doesn't support YAML anchors/aliases (&name / *name) or multi-line block scalars (| or >).
Is my docker-compose.yml uploaded anywhere?
No, all parsing and validation happens locally in your browser using a bundled YAML parser.