You've got 3,000 lines of Terraform spread across 40 files, organized into modules, with variables referencing other variables referencing data sources. It works. It deploys. But can you actually see what it builds?
This is one of the most common challenges in infrastructure-as-code. The code is the source of truth, but it's not visual. You can't glance at a .tf file and immediately understand the architecture the way you can with a diagram.
Here are five practical approaches to visualize your Terraform infrastructure, ranked from simplest to most sophisticated.
1. terraform graph + Graphviz
Terraform has a built-in graph command that outputs a dependency graph in DOT format. You can pipe it through Graphviz to generate a visual diagram.
terraform graph | dot -Tpng > graph.png
This is the quickest approach — one command, no external tools needed (besides Graphviz). It shows every resource and its dependencies, which is useful for understanding execution order.
The problem is readability. For any real-world infrastructure, the output is a massive, tangled web of nodes and arrows. A typical production setup with 50+ resources generates a graph that's essentially unreadable. It includes internal Terraform resources (providers, data sources, variables) that add noise without adding understanding.
Terraform graph is useful for debugging dependency issues — "why is this resource waiting for that one?" — but it's not suitable for architecture documentation.
2. Terraform Visual (VS Code extension)
If you use VS Code, the Terraform Visual extension renders a visual graph of your Terraform resources directly in your editor. It reads your .tf files and generates an interactive diagram that you can zoom, pan, and click on.
The advantage over terraform graph is that it filters out noise and only shows the resources you care about. It also updates in real-time as you edit your code, which is useful during development.
The limitation is that it's tied to VS Code. You can't easily share the output with someone who uses a different editor, and the diagrams aren't suitable for documentation or presentations.
3. Python Diagrams library
The diagrams library for Python lets you define architecture diagrams programmatically. While it doesn't read Terraform files directly, you can write a Python script that mirrors your Terraform architecture.
from diagrams import Diagram, Cluster
from diagrams.aws.compute import EKS
from diagrams.aws.database import RDS, ElastiCache
from diagrams.aws.network import ELB, Route53
with Diagram("Production Architecture", show=False):
dns = Route53("Route 53")
lb = ELB("ALB")
with Cluster("EKS Cluster"):
services = [EKS("api"),
EKS("worker"),
EKS("scheduler")]
db = RDS("PostgreSQL")
cache = ElastiCache("Redis")
dns >> lb >> services
services >> db
services >> cache
This produces clean, professional diagrams with official AWS icons. The Python code can be committed alongside your Terraform code and updated in the same PR. It's a good approach for teams that want version-controlled diagrams.
The downside is duplication — you're maintaining two representations of the same infrastructure (Terraform and Python). When someone adds a new resource in Terraform but forgets to update the diagram code, they drift apart.
4. Paste your code into InfraSketch
This is the approach I built InfraSketch for. Instead of writing separate diagram code, you paste your existing Terraform HCL and the tool generates the architecture diagram automatically.
# Just paste this into InfraSketch:
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
}
resource "aws_eks_cluster" "app" {
name = "production"
vpc_config {
subnet_ids = [aws_subnet.private.id]
}
}
resource "aws_rds_cluster" "db" {
cluster_identifier = "app-db"
engine = "aurora-postgresql"
}
# InfraSketch parses this and generates a
# grouped diagram with AWS icons automatically
The tool parses resource types, detects references between resources, groups them by category (networking, compute, database, etc.), and renders a diagram with official AWS architecture icons. Everything runs in the browser — your code never leaves your machine.
This works well for quick visualization — "let me see what this Terraform actually creates" — and for generating diagrams to include in documentation or README files. The limitation is that it does static analysis only (it doesn't run terraform plan), so it may miss resources created by complex expressions or external modules.
5. Rover (Terraform Visualizer)
Rover is an open-source tool that reads Terraform state files or plan output and generates interactive diagrams. Unlike InfraSketch which does static analysis of HCL code, Rover works with the actual state — meaning it shows exactly what's deployed, including resources created by modules and count/for_each expressions.
# Generate a plan
terraform plan -out=plan.out
# Visualize it
rover -planPath plan.out
Rover produces an interactive web-based diagram that you can zoom, filter, and search. It's more accurate than static analysis because it uses the resolved state, but it requires you to have Terraform initialized and access to the state file.
Which approach should you use?
It depends on what you're trying to accomplish.
If you need a quick visualization while developing, use InfraSketch or the VS Code extension. Paste your code, see the diagram, iterate.
If you need accurate diagrams of what's actually deployed, use Rover with your state file. It's the most accurate because it works with resolved state rather than source code.
If you need presentation-ready diagrams that are version-controlled, use the Python Diagrams library. It takes more effort but produces the most polished output.
If you need to debug dependency chains, terraform graph is still the right tool despite its messy output.
The best approach for most teams is to combine methods: use InfraSketch or Rover for day-to-day visualization, and the Python Diagrams library for documentation that needs to look polished.
Going deeper: Terraform plan JSON
One thing worth calling out separately is the difference between visualizing HCL source files versus visualizing a Terraform plan. Most visualization tools — including InfraSketch's HCL mode — parse your .tf files statically. That means they can't evaluate count, for_each, or variables. If you have count = var.az_count on a subnet, the tool doesn't know how many subnets you actually get.
Terraform plan JSON solves this. When you run terraform plan -out=tfplan && terraform show -json tfplan, you get a fully resolved representation of exactly what Terraform is about to create, update, or destroy. Resource addresses are fully qualified — module.vpc.aws_subnet.private[0], module.vpc.aws_subnet.private[1], module.eks.aws_eks_node_group.workers — and each resource carries a change.actions field indicating what will happen: ["create"], ["update"], ["delete"], or ["create","delete"] for a replace.
InfraSketch reads this format and uses the module address prefix (module.vpc.*, module.eks.*) to automatically group resources into labeled boxes. It also annotates each node with a change badge — green + for creates, amber ~ for updates, orange ↺ for replacements, and red × for deletes. When you're reviewing a PR that changes 30 resources across 6 modules, this visual context is far more useful than reading a raw plan output line by line.
# Generate plan JSON (copy to clipboard on macOS)
terraform plan -out=tfplan
terraform show -json tfplan | pbcopy
# On Linux
terraform show -json tfplan | xclip -selection clipboard
# Paste into InfraSketch → module groups + change badges appear automatically
This is where diagram-from-code approaches become genuinely useful for engineering workflows, not just documentation. You're not just generating a pretty picture — you're getting a structured view of what's changing and what it might affect.
Blast radius: what breaks when you change something?
Understanding what a change affects is one of the most underrated aspects of infrastructure review. In application code, you can trace function calls. In Terraform, you have HCL references — aws_subnet.private.id, module.vpc.aws_security_group.web.id — but tracing them manually across dozens of files is tedious.
Modern visualization tools can automate this. InfraSketch builds a dependency graph from the connections it detects, then lets you click any resource to enter blast radius mode:
- Red border — resources directly downstream (one hop). If you change or delete the selected resource, these break immediately.
- Orange border — indirectly affected (two or more hops). They depend on something that depends on the selected resource.
- Blue border — upstream dependencies. What the selected resource itself relies on.
- Everything else dims, so you can focus on the blast radius.
A side panel lists every affected resource with counts. Clicking any entry in the panel re-centers the blast radius analysis on that resource — useful for understanding cascading dependencies.
This analysis works best with Terraform plan JSON because the connection graph is derived from the configuration.root_module expression references, which are more complete than what static HCL parsing can infer. With HCL, InfraSketch infers connections from resource attribute references; with plan JSON, it uses the resolved dependency graph that Terraform itself computed.
Embedding diagrams in pull request reviews
The most impactful place to surface Terraform visualizations is during code review — not after the fact. If a PR changes six .tf files, reviewers are reading diffs without any visual context. They can't easily tell whether the PR adds a new subnet to an existing VPC or creates an entirely new network segment.
The InfraSketch GitHub Action solves this automatically. It detects when a PR touches .tf files, generates a shareable diagram URL for the changed code, and posts it as a PR comment. The comment updates automatically on each push, so it always reflects the current state of the PR branch.
# .github/workflows/infrasketch.yml
name: Architecture Diagram
on:
pull_request:
paths: ['**/*.tf', '**/terragrunt.hcl']
jobs:
diagram:
runs-on: ubuntu-latest
permissions:
pull-requests: write
steps:
- uses: actions/checkout@v4
- uses: pandey-raghvendra/infrasketch@v4
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
Reviewers see the architecture diagram inline in the PR without any setup. The diagram link opens InfraSketch with the exact code from the PR branch pre-loaded. They can drag nodes, inspect resource details, and analyze blast radius — all from the PR review interface.
This turns diagram generation from a documentation chore into a live engineering tool that's embedded in your existing review workflow.
Common pitfalls when visualizing Terraform
A few things that trip people up when trying to visualize Terraform code:
Missing connections between resources. If you use intermediate variables or locals to pass resource IDs, static analysis tools may not detect the connection. For example, local.private_subnet_ids passed to an EKS cluster creates an implicit dependency that HCL parsers can miss. The fix: use Terraform plan JSON instead of HCL — plan JSON includes the fully resolved reference graph.
Cross-file references aren't resolved. Most HCL parsers work on individual files. If your VPC is defined in vpc.tf and your EKS cluster is in eks.tf, a parser that only reads one file will show an isolated node for each. The solution: concatenate your .tf files before pasting (cat *.tf | pbcopy), or use plan JSON which sees the entire configuration.
Module resources appear as opaque nodes. With HCL, module "vpc" { source = "./modules/vpc" } renders as a single box — the tool can't see inside the module without reading the module source. Terraform plan JSON expands modules to their full module.vpc.* resource addresses, giving you visibility into what each module actually creates.
Count and for_each resources are missing or multiplied. Static HCL analysis can't evaluate expressions, so count = 3 might render as one node or be skipped entirely. Plan JSON has the actual instances with their full addresses (aws_subnet.private[0], [1], [2]), so you get an accurate picture.
Frequently asked questions
Does InfraSketch run terraform plan for me?
No. InfraSketch does static analysis of the code you paste. It doesn't execute Terraform, access your cloud credentials, or connect to remote state. If you want the most accurate visualization, run terraform show -json tfplan yourself and paste the JSON output.
Can I visualize multiple Terraform workspaces?
Each workspace gets its own plan JSON when you run terraform plan. You can paste each plan separately to get separate diagrams. There's no side-by-side diff view yet, but the plan change badges (+/~/↺/×) on each node make it easy to see what changed in any given workspace's plan.
What about Terragrunt?
InfraSketch has a Terragrunt parser that handles terragrunt.hcl files. It detects dependency blocks and generates connection arrows between dependent stacks. For the most accurate view of a Terragrunt monorepo, concatenate the HCL files or use terragrunt run-all plan --terragrunt-json-out-dir ./plans to generate plan JSON for each stack.
Do diagrams go stale?
They do if you generate them manually. The solution is the GitHub Action — it regenerates the diagram on every PR push, so the diagram in the PR comment always matches the current branch. For documentation, regenerate the diagram when you make infrastructure changes, the same way you'd update any other technical doc.
Visualize your Terraform instantly Paste your Terraform HCL and see the architecture diagram in seconds. Now with an interactive drag-and-drop editor, GCP support, and more. Open InfraSketch
Top comments (0)