Terraform Guide

Terraform diagrams without state, init, or credentials: parse the source

Most Terraform visualization tools want a plan file, a state file, or worse, live credentials into your cloud account. That is a hard sell for the exact repositories people most want drawn: production platforms, client infrastructure, anything under change control. The alternative is to treat the .tf source as what it is, a complete declaration of the architecture, and parse it.

Try it free
6 min readFor engineers who cannot or will not hand a diagramming tool their state file

See it as a diagram

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

148/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

Why state-based visualization is a non-starter for many teams

State files contain real resource ids, IP addresses, connection strings, and sometimes secrets that providers chose to store. Handing state to a third-party tool is a security review nobody wants to run. Plan-based tools are gentler but still need init, which means provider downloads, backend access, and a machine allowed to reach both.

Consultants and platform teams hit a second wall: on a client engagement you often have read access to the repository and nothing else. The tool that needs credentials is the tool you cannot use.

What source parsing can and cannot see

The source declares everything the architecture IS: resources and their types, modules and their boundaries, references between them, count and for_each shapes, per-environment values in tfvars. Datadef parses all of it, resolves variables through call sites and locals to literal values where they exist, and follows module outputs to build the real cross-resource graph.

What source cannot tell you is runtime state: whether the apply succeeded, actual instance ids, drift between code and cloud. That is a different question with different tools. For the architecture question, what exists and how it wires, the source is authoritative by definition: it is what terraform apply will make true.

What the connection needs:
  - repository read access (public repos: nothing)
  - a branch or tag name

What it never touches:
  - terraform state
  - your cloud account
  - terraform init / plan / apply

The loop this enables

Because parsing needs nothing but read access, the diagram can regenerate on every sync without ceremony: daily, on demand from the UI, or from an MCP client when your coding agent finishes a change. The result lands on an editable canvas, exports as PNG or JPEG, and embeds in READMEs and wikis as a live image.

Multi-environment repos come out honest rather than tripled: tfvars are parsed per environment, so a resource created per environment is one node stating DEV, QUAL, and PROD counts, not three copies of the platform.

FAQ

Is the source really enough to draw the architecture?

For the architectural questions, yes: the source declares every resource, module, and reference that apply will create. What the source cannot show is runtime state and drift, which are monitoring questions rather than architecture ones.

How do variables get their values without running terraform?

Literal values are resolved by following the wiring: call-site bindings, variable defaults, and tfvars files, including per-environment tfvars. A value that differs across environments is either shown per environment or left out rather than guessed.

What access does the repository connection use?

A read-only token for GitHub, GitLab, or Azure DevOps, scoped to reading the repository. Public repositories need no token at all. Nothing is cloned to your machine and nothing is executed.

Can this run against a client repository I only have read access to?

Yes, that is the intended case. Read access to the repo is the entire requirement, which is what makes it usable on client engagements where credentials and state are off the table.