Docker Guide

Docker Compose visualizer: the stack, its images, and its pipeline together

By the engineer who builds Datadef, from client work on data platforms · Reviewed August 21, 2026

docker-compose-viz and its descendants answer a narrow question well: given one compose file, draw the services and the links between them. The answer is a DOT or Mermaid graph, produced once, from one file. A repository has more to say than that. The Dockerfiles say what each service is built from, the CI pipeline says how it ships, and the override files say how the stack differs in production.

Try it free
6 min readFor teams whose local and staging environments are defined by Compose files

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

179/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

Every compose file, not just the first one

The selector matches on the file name prefix: anything whose name starts with docker-compose is treated as a Compose file. That takes docker-compose.yml, docker-compose.override.yml, docker-compose.prod.yml, and docker-compose.test.yml in the same pass, up to 6 files by default and 8 under the architecture focus, which is what you want because the differences between them are where the interesting architecture lives. The same rule means a forgotten docker-compose.backup.yml also spends one of those slots, so deleting the dead ones is worth a minute.

Dockerfiles are matched the same way, on the name prefix, so Dockerfile, Dockerfile.api, and Dockerfile.worker all come along in their own class with the same ceilings. A stack where four services build from four different Dockerfiles produces a diagram that can say what each service actually is, rather than four identical boxes named after their compose keys.

One thing to know if your project uses the newer file name: the match is on the docker-compose prefix, so a file named compose.yaml registers in the repository tree summary rather than in the Compose class. Keeping a docker-compose.yml name, which Compose still reads, puts it back in the corpus.

Compose class (name starts with docker-compose)
  docker-compose.yml
  docker-compose.override.yml
  docker-compose.prod.yml

Container image class (name starts with dockerfile)
  Dockerfile
  Dockerfile.api
  Dockerfile.worker

Read alongside them
  .github/workflows/ci.yml    package.json / pyproject.toml / go.mod    README.md

What ends up on the canvas

The depends_on graph gives the ordering edges, the ports give the entry points, the volumes give the persistence, and the environment blocks give the connections that leave the stack: the database URL, the broker host, the object storage endpoint, the third-party API base. Those environment values are usually the most informative lines in the whole file, and they are the ones a link-only graph throws away.

Services render with the icon of what they actually are. A postgres image gets the Postgres mark, redis gets Redis, a kafka or redpanda service gets the broker mark, and a service that builds from a local Dockerfile gets the mark of the runtime that Dockerfile starts from where the base image says so.

The result is one canvas you can edit rather than a fixed render: rename a service, add the annotation about why the worker has two replicas, group the data services into a zone. Export is PNG or JPEG when you need a file to attach.

The part a one-off render cannot do

Connect the repository once, read-only, on GitHub, GitLab, or Azure DevOps, and the diagram becomes a property of the branch instead of a file in a downloads folder somewhere. It regenerates on a daily sync, skips commits where nothing moved, and restores the position of any node you dragged, so a re-sync updates the picture instead of reshuffling it.

Drop one markdown image line in the README and every contributor sees the current stack when they open the repository, through a live embed that needs no account to view. That is the difference between a diagram you generated and a diagram your team has.

Compose plus the rest of the repo

The corpus is capped at 40 files and 250KB, and the Compose and Dockerfile classes have ceilings of their own, so a large stack still leaves room for the CI pipeline and the dependency manifests. See how repository sync works.

When Compose is only half the story

Plenty of repositories use Compose for local development and something else in production. When that something else is a set of deployment manifests, the sync reads those too: YAML under a directory named k8s, kube, kubernetes, manifests, charts, or helm is classified at container priority alongside the Compose file. The diagram can then carry the local stack and the deployed one as two zones over the same services.

When production is Terraform, the repository takes a different path entirely: every .tf file is parsed into stacks, modules, and resources before anything is drawn. Read visualize a Terraform repository for what that produces.

On the first sync the counts are stated in one deterministic sentence composed without any model call, for example: Mostly Docker Compose files and Dockerfiles (12 files) with 3 data model and API files. That sentence is what the focus choice is made against.

FAQ

Does it read override and per-environment compose files?

Yes. Any file whose name starts with docker-compose is picked up, so docker-compose.yml, docker-compose.override.yml, and docker-compose.prod.yml are read together, up to six files by default and eight under the architecture focus. The differences between them are usually the most useful part of the stack, because that is where production stops looking like a laptop.

My file is named compose.yaml. Does that work?

The Compose class matches names starting with docker-compose, so a file named compose.yaml appears in the repository tree summary rather than in the fetched Compose files. Naming it docker-compose.yml, which Compose still supports, puts it into the corpus.

Are the Dockerfiles read too?

Yes, in their own class, matched on the file name prefix so Dockerfile.api and Dockerfile.worker are included. That is what lets the diagram say what each service is built from instead of only what it is named in the compose file.

Do I need Docker installed or the stack running?

No. Nothing is executed, no image is pulled, and no container is started. The sync reads the files from the connected repository with read-only access on GitHub, GitLab, or Azure DevOps, so the diagram can be produced for a branch nobody has run yet, or for a stack you were sent to review and have no intention of starting.

How is this different from docker-compose-viz?

A CLI renders one file to a graph, once. A repository connection reads the compose files together with the Dockerfiles, CI pipelines, and dependency manifests, redraws from the branch on a daily sync, keeps hand-placed nodes where you put them, and serves the current diagram through an embed URL for the README.