Docker Compose Validator
Check a compose file for structural errors, bad references and dependency cycles.
Catch It Before The Engine Does
Compose failures are rarely interesting. A volume that was renamed in one place and not another, a service that depends on something that no longer exists, a port mapping that YAML quietly read as a base-60 number because nobody quoted it. Each is a one-line fix that costs a deploy cycle to find.
This checks the structure of the file: whether it parses, whether every service can actually be built or pulled, whether references resolve, and whether the dependency graph is sound. It works out the start order too, which is the question depends_on is really answering.
Key features
- Parses the YAML properly — anchors, block scalars and flow collections, with the line number named when it fails.
- Resolves references — named volumes, networks and depends_on targets are checked against what the file declares.
- Finds dependency cycles — which Compose refuses to start, with the loop named.
- Catches the YAML port trap — an unquoted 22:22 is read as sexagesimal, and the file starts wrong rather than failing.
- Shows the start order — services grouped into tiers, so you can see what waits for what.
This tool runs entirely inside your browser using native Web APIs. Your files and text are never uploaded to a server, never logged and never shared with third parties.
How to use: Docker Compose Validator
- Paste the compose file
Or load the example to see the kind of thing it reports. - Read the findings
Errors would stop Compose. Warnings are things that work but will bite later. - Check the start order
Services on the same row start together; anything unexpected there is a missing depends_on. - Fix and re-check
The report updates as you type.
Technical specifications
| Processing location | Entirely in your browser — no server round trip |
|---|---|
| Data uploaded | None. Files and text never leave your device |
| Price | Free — no account, no trial, no usage cap |
| Category | Developer |
| Works offline | Yes, once the page has loaded |
| Browser support | Chrome 90+, Edge 90+, Firefox 90+, Safari 15+ |
| Interface languages | English, 中文, हिन्दी, Español, العربية |
Frequently asked questions
Does this check that my images exist?
No — that would need to contact a registry, and nothing here leaves your browser. It checks structure: that every service names an image or a build, that references resolve within the file, and that the syntax is what the engine expects. A typo in an image name is not something it can catch.
Why does it warn about the version key?
Because it has been obsolete since Compose v2 and is ignored. It is harmless, but it is also a reliable sign that a file was copied from a pre-2020 tutorial, and files of that vintage usually carry other habits worth revisiting.
What is the problem with ports written as 22:22?
Unquoted, YAML reads it as a sexagesimal number — base 60 — so it becomes 1342. The container then publishes a port nobody expects, and nothing reports an error. Always quote port mappings. The validator flags any mapping that was parsed as a number rather than a string.
Why is depends_on flagged as not enough?
It is not flagged as wrong, but it is worth knowing that depends_on controls start order, not readiness. A database container is "started" long before it accepts connections, so an application that depends on it will still fail at boot. Use a healthcheck with a condition, or make the application retry.
Does it support every Compose feature?
It knows the service keys in common use and the top-level blocks, and it warns rather than errors on anything it does not recognise — because Compose ignores unknown keys, which means a typo fails silently. Very new or experimental keys may show as warnings; that is a prompt to check the spelling, not a verdict.