Paste docker-compose.yml and see your service graph — dependencies, ports, volumes, networks, all rendered visually
Lint findings
Dependency graph
Docker Compose Visualizer parses a docker-compose.yml file and renders it visually: each service as a card showing image, ports, volumes, environment variables, and networks, with depends_on arrows linking services in a dependency graph. It also runs a set of lint checks for the most common production mistakes and outputs the dependency graph as Mermaid syntax for use in documentation.
docker-compose.yml content into the input area, or upload the file directly.depends_on arrows — follow them to understand startup ordering.| Issue | Example | Severity |
|---|---|---|
| Port collision | Two services binding 8080:80 | High |
| Orphan network | Network declared but no service uses it | Low |
| Missing depends_on | App references DB env vars but no depends_on | Medium |
| Circular dependency | A depends on B depends on A | High |
Implicit latest tag | image: postgres (no version pinned) | Medium |
| Missing restart policy | No restart: on long-running services | Low |
| Privileged container | privileged: true | Medium |
| Dangerous bind mount | /:/host or similar | High |
A two-service compose file — app and database — is readable as text. You can hold the whole thing in your head. At five services, you’re scrolling to trace a dependency. At ten services, you’re grep-ing the file to find which service exposes which port. At fifteen or more services (which is not unusual in a home lab or microservices stack), the compose file is actively opaque — you can’t see the startup order, you can’t tell which services share a network, and you can’t spot port conflicts without a systematic scan.
The visual card layout answers the most common questions instantly:
The dependency graph is the highest-value output for debugging. depends_on controls startup ordering: service B won’t start until service A is running (or healthy, if condition: service_healthy is set). When services fail to connect to a dependency on startup, the most common cause is missing or incorrect depends_on — the dependent service started before its dependency was ready.
The graph makes this visible: if your api service doesn’t have an arrow to your postgres service, api may start before postgres is ready, fail the database connection, and exit. With the graph, you see the gap. Add depends_on: postgres (or better, condition: service_healthy with a postgres healthcheck) and restart.
Common production mistakes surfaced by the graph:
Missing depends_on for shared databases. The most common mistake. Services assume the database is up because it was manually started first during development. In automated deployments, there’s no such guarantee.
No restart policy. A service with no restart: directive stops permanently if it crashes. For any production service, restart: unless-stopped or restart: on-failure should be the default. The lint check flags every long-running service without a restart policy.
Implicit latest tag. image: postgres resolves to postgres:latest at pull time. In 6 months, latest is Postgres 17 instead of 16, and your schema migrations break. Always pin a version: image: postgres:16.2.
Port collisions. When two services try to bind the same host port, Docker Compose will fail on startup with an unclear error. The lint check finds collisions before you try to start the stack.
Orphan networks. Declaring a network in the networks: block but not attaching any service to it produces a dangling network that Docker creates but nothing uses. Cleanup debt.
The Mermaid output pastes directly into:
Example output for a 4-service stack:
graph TD
nginx --> api
api --> postgres
api --> redis
This becomes a rendered diagram in any Mermaid-supporting viewer. For infrastructure docs — README files, runbooks, architecture decision logs — this is significantly clearer than a wall of YAML.
docker compose up --build. Catching a port collision here saves the time of a full build cycle.& and *), multi-doc files (---), or ${VAR} environment variable substitutiondeploy: blocks are read but not deeply analyzedbuild: graph — only services with an image: are graphed; multi-stage build chains aren’t traverseddocker-bench-securityFor informational purposes only. Not financial, medical, or legal advice. You are solely responsible for how you use these tools.