Generate from source

Generate an architecture diagram from docker-compose.yml.

A Compose file is already a complete description of a small system. It is just written in a format that hides the shape.

Download for macOS
v0.1.33 · .dmg · Apple Silicon & Intel
Signed & notarized by Apple · opens without a Gatekeeper warning
sha256 698955a0187bc039f4c74f5d05a9f10fbb27376a45788a0a241d1326b73873c7
Download for Windows instead
$curl -fsSL https://lucidtrain.com/install.sh | sh

What it reads

The services block, which is the component list; depends_on, which gives explicit ordering edges; ports, which identifies what is reachable from outside; volumes, which identifies what holds state; networks, which shows what can reach what; and environment variables, which are usually where one service's address appears inside another and are therefore where the real edges hide.

How Compose becomes components

Each service is a component. Images map to tiers by recognisable name: postgres, mysql, mongo and redis go to data, nginx and traefik go to edge, and anything with a build context is application. Published ports put a component at the edge of the diagram, and a named volume marks a service as stateful, which is the distinction that matters most when someone is deciding what can be restarted safely.

Why the layout can be trusted

The agent reads the files listed above and emits a semantic graph: components, the tier each belongs to, and the edges between them, with no coordinates anywhere. The ELK layout engine then computes positions and orthogonal edge routing. This is why the output cannot come back with boxes overlapping or arrows crossing through cards, which is the usual failure when a language model is asked to place things on a canvas itself.

Useful mainly for onboarding

A Compose file is the first thing a new engineer runs and among the last things they understand. Turning it into a picture on day one, and keeping that picture in the README, converts a file people copy commands out of into an explanation of what they just started.

Your Compose file stays on your machine

It runs on your machine. With a local Ollama model nothing leaves the laptop at all, and with your own API key the file contents go to the provider you chose and never through us. For a source that is your actual codebase, that distinction is usually the deciding one.

Compose to diagram

In the fileIn the diagram
services entriesOne component each
depends_onExplicit ordering edges
portsMarks a component as externally reachable
volumesMarks a component as stateful, data tier
networksWhich components can reach which
environment referencing another serviceAn inferred edge
image: postgres, redis, mongoData tier
image: nginx, traefik, caddyEdge tier
build:Application tier, your own code

The prompt

shell
$ Read docker-compose.yml and diagram the stack: which services exist, which depend on which, what holds state, and what is exposed.
FAQ

Questions

Does it need Docker installed?

No. It reads the YAML file, so it works on a machine that has never run a container.

Does it handle multiple compose files and overrides?

Yes, including the override pattern, and merging them first gives the most accurate result since that is what Compose itself would use.

Will it infer edges that are not in depends_on?

It will, from environment variables and network membership, and those inferred edges are the ones most worth checking. depends_on is frequently incomplete because it only affects startup ordering, so relying on it alone understates the real coupling.

Is this useful for production systems?

As a starting point that you then correct. For production, Terraform or Kubernetes manifests are a far better source because they describe what actually runs.

Related