Generate an architecture diagram from a GitHub repository.
Clone it and point the app at the directory. Private repositories work exactly the same way, because nothing is uploaded to make it work.
How it works
There is no repository URL field, and that is the design rather than a missing feature. You clone, the app reads the working directory, and the analysis runs where the code already is. Anything you can clone, you can diagram, including private repositories, internal mirrors and hosts that are not GitHub, without granting an integration access to your account.
What it reads
The same survey as any codebase: manifests, README, compose and deployment files first to establish what the project is, then entry points and the import graph outward to find the boundaries. Git history is available as context when you want it, which is occasionally useful for identifying which parts of a system are actively changing and which are effectively frozen.
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.
Understanding a repository you did not write
This is the common case: an unfamiliar open source project, a service inherited from a team that has moved on, or something a coding agent generated over several sessions. A diagram is a much faster way in than a file tree, and being able to ask questions of the diagram afterwards is faster still.
Nothing is uploaded
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.
Compared with hosted repo-to-diagram tools
| Lucid Train | Hosted tools | |
|---|---|---|
| Private repositories | Clone locally, no access granted | Requires OAuth access to your account |
| Where the code goes | Stays on your machine | Uploaded or read by their servers |
| Non-GitHub hosts | Anything you can clone | Usually GitHub only |
| Offline | Works with a local model | No |
| Editing the result | Edit the graph, layout re-solves | Usually regenerate and hope |
| Diagram to code | Yes, as a specification for a coding turn | No |
Clone, then diagram
Questions
Do I have to give it access to my GitHub account?
No. You clone with the credentials you already use, and the app reads a directory. There is no integration to authorise and nothing to revoke later.
Does it work with GitLab, Bitbucket or a self-hosted host?
Yes. It works on directories, so how the code got there is irrelevant.
Can it diagram a monorepo?
It can, and one package or service at a time reads far better than everything at once. A diagram of an entire monorepo is usually accurate and useless.
How current is the diagram?
As current as your working tree. Rerunning after a pull is quick, which is what makes keeping it in the README realistic rather than aspirational.
Related
- Generate a Diagram from a SQL SchemaForeign keys already record the relationships. An ER diagram is a rendering of constraints the database is enforcing anyway.
- Generate a Diagram from an OpenAPI SpecAn OpenAPI document is exhaustive and unreadable. The useful diagram is not every endpoint, it is the shape underneath them.
- Generate an AWS Architecture DiagramIt reads your infrastructure as files rather than by connecting to your account, which means it needs no credentials and works against environments you cannot reach.
- Generate a Diagram from a MonorepoThe hard part of diagramming a monorepo is not reading it, it is deciding what to leave out.
Last updated