Generate an architecture diagram from Terraform.
Terraform already describes your infrastructure precisely. The diagram is a rendering of something you have written down, not a guess.
What it reads
Every .tf file in the directory tree, plus variables and locals so that names resolve to something meaningful rather than to an interpolation. If a state file or a saved plan is available it reads that too, which is a meaningful upgrade: configuration tells you what should exist, state tells you what does, and the two differ more often than anyone likes. Modules are followed into their source directories so a diagram of a root module is not just a diagram of module blocks.
How resources become components
Resource types map onto tiers: compute and container services into the application tier, managed databases and buckets into data, load balancers and gateways into edge, and anything from a provider you do not run into external. Edges come from references between resources, which is the part that makes Terraform such a good source. When one resource interpolates another's attribute, that is a real dependency the language has recorded for you, so the edges are read rather than inferred.
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.
Where it beats reading the console
A cloud console shows you resources grouped by service type, which is the least useful grouping for understanding a system. Terraform is already organised by intent, so the diagram comes out grouped the way you think about it. It also covers everything in the configuration at once, rather than requiring you to visit six product pages to assemble a mental picture.
Your configuration 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.
Terraform to diagram
| In the configuration | In the diagram |
|---|---|
| *.tf, *.tfvars | The resource set that is drawn |
| terraform.tfstate or a saved plan | What actually exists, rather than what is declared |
| module blocks, followed to source | Grouped components rather than opaque boxes |
| References between resources | Edges, read from the configuration rather than inferred |
| depends_on | Explicit ordering edges |
| Compute and container resources | Application tier |
| Managed databases, caches, buckets | Data tier |
| Load balancers, gateways, CDN | Edge tier |
| Third-party providers | External tier |
The prompt
Questions
Related
- Generate a Diagram from a CodebasePoint it at a repository and it surveys the code the way a new engineer would, then draws what it found.
- Generate a Diagram from Kubernetes ManifestsKubernetes YAML contains the whole topology and presents it as several hundred lines in which none of it is visible.
- Generate a Diagram from Docker ComposeA Compose file is already a complete description of a small system. It is just written in a format that hides the shape.
- Generate a Diagram from a GitHub RepoClone it and point the app at the directory. Private repositories work exactly the same way, because nothing is uploaded to make it work.