Free Docker Compose Visualizer
Paste a Compose file to see every service, its image and ports, and the order depends_on starts them in.
What is a Docker Compose Visualizer?
A Docker Compose file describes the containers an application needs and how they depend on each other. This visualizer reads a docker-compose.yml and draws the services as a diagram, with an arrow for every depends_on link.
It follows the Compose Specification used by docker compose v2, reading both the short list form of depends_on and the long form with a condition such as service_healthy. Before drawing, it checks that every dependency exists and that there are no loops, the two problems that stop docker compose up.
Key Features
Start Order at a Glance
Arrows point from each service to the ones it waits for, labelled started, healthy or completed. You can see what boots first without reading the YAML.
Missing Services and Loops Caught
A depends_on that names a service that doesn’t exist, or a cycle between services, is reported before you run docker compose up.
Images, Builds and Ports Listed
Each node shows the image or build context and published ports, and the table adds networks. Long-form ports are written the short way.
Anchors and Extension Fields Resolved
Shared settings in x- blocks merged with <<: *anchor are applied, as Compose applies them, so templated workers show their real dependencies.
Mermaid Source to Reuse
Switch to Mermaid source to copy the diagram as text into a README, a wiki or a pull request that renders Mermaid.
Perfect for everyone
- Developers onboarding to a project
- DevOps engineers reviewing Compose files
- Teams documenting their local development stack
How to Use the Docker Compose Visualizer
Paste the file, check the graph, and copy it if you want to document it.
Paste the Compose File
Copy docker-compose.yml, compose.yaml or an override file into the box. Top-level volumes, networks and x- blocks can stay in.
Read the Diagram
Each box is a service with its image or build context and ports. An arrow from A to B means A waits for B, and the label says whether it waits for started, healthy or completed.
Fix What’s Flagged
If a service depends on a name that doesn’t exist, or services wait on each other in a loop, the error says which ones. Fix the YAML and the graph redraws.
Copy the Mermaid Source
Switch to Mermaid source and copy it into Markdown inside a mermaid code block. GitHub, GitLab and many wikis render it as the same diagram.
Compose Files and the Graphs They Make
Each answer is the Mermaid source this visualizer produced for the Compose file on the left, or the error it reported. Picture the arrows before you reveal it.
“services: web: image: nginx:1.27 depends_on: [api] api: image: node:22-alpine”
“services: api: image: acme/api depends_on: db: condition: service_healthy db: image: postgres:16”
“services: api: image: acme/api depends_on: migrate: condition: service_completed_successfully migrate: image: acme/api command: npm run migrate”
“services: web: build: ./web ports: - "8080:80" - target: 443 published: 8443”
“x-worker: &worker image: acme/worker depends_on: [queue] services: queue: image: rabbitmq:3 emails: <<: *worker thumbnails: <<: *worker”
“services: proxy: image: traefik:v3 ports: ["80:80"] depends_on: [app] app: image: acme/app depends_on: [db] db: image: mysql:8”
“services: web: image: nginx depends_on: [api]”
“services: a: image: acme/a depends_on: [b] b: image: acme/b depends_on: [a]”
“services: web: image: nginx ports: ["80:80"]”
“version: "3.9" networks: default: {}”
The Compose Keys Behind the Graph
Only a few keys decide what the diagram shows. These are the ones the visualizer reads, as the Compose Specification defines them.
services
The required top-level map, one entry per container. Each key becomes a box in the diagram and a hostname on the default network.
“Can a Compose file have no services?”
image
The image to run, with an optional tag or digest, such as postgres:16. A missing tag means latest, which can change without warning.
“Which tag does image: redis use?”
build
Builds the image from a Dockerfile, written as a path or a map with context and dockerfile. The node shows the context path.
“Where does build: ./web look for a Dockerfile?”
depends_on, Short Form
A list of service names to start first. Compose only waits for those containers to start, not to be ready.
“Does depends_on: [db] wait for the database to accept connections?”
depends_on, Long Form
A map of services with a condition: service_started, service_healthy or service_completed_successfully. The edge label shows which.
“Which condition waits for a healthcheck to pass?”
healthcheck
A test command Docker runs on a timer to mark a container healthy. service_healthy dependencies need one, or they wait forever.
“What does service_healthy need on the dependency?”
ports
Publishes container ports on the host as HOST:CONTAINER, such as 8080:80. Long form uses published and target keys.
“In 8080:80, which port is on your machine?”
networks
Services join the default network unless they list others, and only services sharing a network can reach each other by name.
“Can services on different networks reach each other by name?”
volumes
Mounts named volumes or host paths into a container. Named volumes are declared at the top level and keep data between runs.
“Which survives docker compose down, a named volume or a container’s filesystem?”
Extension Fields and Anchors
Top-level keys starting with x- are ignored by Compose, which makes them a place for YAML anchors. Services merge them in with <<: *name.
“Does Compose run a service called x-worker?”
How Compose Starts and Stops Services
The graph is the order Compose follows. These rules explain what it means at run time.
Dependencies Start First
docker compose up creates and starts services in dependency order, so the database in a web, api, db chain starts before the API.
Stopping Happens in Reverse
docker compose down stops dependents before their dependencies, so the web container stops before the API it calls.
Started Isn’t Ready
The default condition only waits for the container to start. Use service_healthy with a healthcheck when the dependency needs time to accept connections.
One-Off Tasks Can Gate Others
service_completed_successfully waits for a container to exit with code 0, which suits migrations and seeding jobs.
Starting One Service Brings Its Dependencies
docker compose up api also starts everything api depends on. Add --no-deps to start only the named service.
Loops Stop Everything
If two services depend on each other, Compose reports a dependency cycle and starts nothing. Break the loop, often by removing a dependency that isn’t really needed at startup.
Compose Dependency Mistakes
Most start-up failures in Compose come down to one of these.
Expecting depends_on to Wait for Readiness
A web app that connects to the database at boot can fail because the database is still starting. Add a healthcheck and the service_healthy condition.
Typos in Service Names
depends_on: [postgres] when the service is named db stops Compose before anything starts. The visualizer flags the unknown name.
Tabs in YAML
YAML indentation must use spaces. A single tab, often pasted from an editor, breaks the whole file.
Forgetting the Healthcheck
service_healthy waits forever on a dependency that has no healthcheck. Define a test command on the service being waited for.
Port Clashes on the Host
Two services publishing the same host port fail to start, and so does one using a port another program already holds. Check the Ports column.
Relying on the Version Key
The top-level version field is obsolete in Compose v2 and ignored, apart from a warning. Remove it rather than bumping it.
Override Files Hiding Changes
docker compose merges compose.override.yaml automatically. Visualize the merged result from docker compose config when something looks off.
Using latest in Shared Stacks
image: postgres without a tag pulls whatever latest is today. Pin a version so everyone runs the same stack.
Healthchecks for service_healthy
A healthy dependency needs a test command. These are common ones for the services people wait on most.
PostgreSQL
Run pg_isready -U postgres as the test. It reports ready only once the server accepts connections.
MySQL and MariaDB
Use mysqladmin ping -h localhost, or healthcheck.sh --connect in the official MariaDB image.
Redis
redis-cli ping returns PONG when the server is ready. Add the password flag if the instance requires authentication.
HTTP Services
Request a health endpoint with wget -qO- or curl -f, choosing whichever tool the image includes. Slim images often have neither, so add one or use a small binary.
Interval, Timeout and Retries
interval sets how often the test runs, and retries how many failures mark the container unhealthy. start_period gives slow starters a grace period.
Check the Status
docker compose ps shows healthy, unhealthy or starting for each service. docker inspect shows the last test results when a check keeps failing.
When a Compose Graph Helps
Whenever you need to understand a stack faster than by reading YAML.
Onboarding to a New Project
See what the local stack contains and how the pieces depend on each other before running it for the first time.
Reviewing a Compose Change
Paste the file from a pull request to check that a new service is wired to the right dependencies.
Documenting the Stack
Copy the Mermaid source into the README so the architecture diagram lives next to the code and stays easy to update.
Debugging Start-Up Order
When a service crashes because its dependency wasn’t ready, check which condition its arrow uses.
Planning a Migration to Kubernetes
Use the graph and table as an inventory of services, images, ports and volumes to translate into manifests.
Teaching Docker Compose
Show how depends_on, healthchecks and conditions shape start-up, with a diagram that redraws as students edit.
Auditing Exposed Ports
The Ports column lists every published port in one place, so nothing is exposed on the host by accident.