What this shows
Paste a docker-compose.yml and see it laid out instead of read top to bottom: a card per service with its image or build source, published ports, and depends_on relationships; a reverse index of which services share each network and each named volume (Compose files describe those from each service's own side, which gets hard to mentally reassemble once a file has more than three or four services); and a start-order diagram computed from the dependency graph — which services can start in parallel, and in what sequence, grouped into "waves."
If the dependency graph has a cycle (two or more services depending on each other, directly or transitively), that's flagged explicitly — Compose can never resolve a start order for those services, and the usual symptom is a confusing timeout or restart loop rather than an obvious error at deploy time.
What it doesn't do
This is a read-only view built from the file's structure — it doesn't validate the file (bad ports, undeclared volumes, typo'd service references) or check whether referenced images or build contexts actually exist. For that, use the Docker Compose Validator.
FAQ
Why do some services end up on a network I didn't list?
Any service with no networks: of its own is placed on the implicit default network by Compose. This tool shows that the same way — a service with no explicit networks appears under a "default" group here too.
Can I edit the file here?
This tool is read-only by design — to fix indentation, use the Docker Compose Formatter; to catch mistakes before they reach a real deploy, use the Docker Compose Validator.