DEV Community: Adnan H. Çelik

Terraform to Architecture Diagram Without a Plugin

Adnan H. Çelik — Fri, 16 Oct 2026 21:00:54 +0000

Every infrastructure repo I have joined had the same two artefacts side by side: a folder of .tf files that described the system exactly, and a diagram in the wiki that described it roughly, as of some quarter in the past.

Nobody wants it that way. The problem is that turning Terraform into a picture has always come with a toll:

terraform graph needs an initialised working directory, downloads providers, and produces a DOT dependency graph that is accurate and nearly unreadable once you pass a dozen resources.
Most "Terraform visualiser" tools want a plan file, a state file, or cloud credentials, and some want a plugin in your pipeline before they show you anything.

All I usually want is to look at the code I am reviewing and see its shape. So this post is about doing exactly that, with nothing installed: paste HCL, get a diagram you can edit.

I am using LetDraw for this. It is a whiteboard with a Generate from Code dialog that reads Terraform (and OpenTofu, which shares the syntax) as text.

The example

A small but realistic AWS stack: a VPC with a public and a private subnet, an ALB in front of an ECS service, a Postgres RDS instance, an S3 bucket, a monitoring module, a variable and an output.

variable "env" {
  default = "prod"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

resource "aws_subnet" "private" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.2.0/24"
}

resource "aws_security_group" "web" {
  name   = "web-sg"
  vpc_id = aws_vpc.main.id
}

resource "aws_lb" "app" {
  name            = "app-${var.env}"
  subnets         = [aws_subnet.public.id]
  security_groups = [aws_security_group.web.id]
}

resource "aws_lb_target_group" "app" {
  name   = "app-tg"
  vpc_id = aws_vpc.main.id
}

resource "aws_ecs_cluster" "main" {
  name = "checkout"
}

resource "aws_ecs_service" "api" {
  name            = "api"
  cluster         = aws_ecs_cluster.main.id
  subnets         = [aws_subnet.private.id]
  load_balancer_target_group_arn = aws_lb_target_group.app.arn
}

resource "aws_db_instance" "orders" {
  identifier     = "orders"
  engine         = "postgres"
  instance_class = "db.t4g.medium"
  db_subnet_group_name = aws_subnet.private.id
}

resource "aws_s3_bucket" "assets" {
  bucket = "checkout-assets"
}

module "monitoring" {
  source  = "./modules/monitoring"
  cluster = aws_ecs_cluster.main.name
}

output "lb_dns" {
  value = aws_lb.app.dns_name
}

Paste it into the dialog (or use Load file on a .tf), switch on Add icons, and insert:

That is 13 blocks and 13 relationships, grouped into Variables, AWS, Modules and Outputs, with a product icon on each AWS resource. Every box and arrow is a normal shape on a whiteboard, so the next step is the part a generator can never do for you: drag things into the layout your team actually talks about, add the third-party payment API that Terraform knows nothing about, and circle the part you are worried about.

What it actually reads

It helps to know what the parser does, so you know what to expect from your own code. It is a static reading of the HCL text:

Blocks become nodes. resource, data, module, variable and output blocks each become a box. provider, locals and the terraform {} block are configuration, so they are skipped to keep the picture clean.
References become arrows. Any interpolation that points at another declared block draws an arrow from the dependency to the dependent: aws_subnet.public.id, data.aws_ami.ubuntu.id, module.network.vpc_id, var.env, and the entries of a depends_on list.
Arrows are labelled with the attribute that created them. subnet_ids = [aws_subnet.private.id] becomes an arrow labelled "subnet"; security_groups = [...] becomes "security groups". The suffixes _id, _ids, _name and _arn are dropped, so labels read like English.
Cards show what matters. The title is a friendly type name (aws_db_instance reads "DB Instance", azurerm_virtual_network reads "Virtual Network"). Under it you get the literal name if there is one, plus up to two key attributes such as cidr_block, engine, instance_class, location or sku. Interpolated values are left out rather than shown half-resolved.
Groups follow the provider. AWS, Azure, Google Cloud, Kubernetes, Cloudflare, GitHub and other providers each get their own group, so a multi-cloud repo separates itself visually.

Arrows only connect blocks that exist in what you pasted. If module.network is not in the text, a reference to it is simply ignored instead of inventing a phantom box.

Make it readable: hide the noisy relationships

The honest first result of any infrastructure graph is too many arrows. In almost every AWS stack, everything points at the VPC, and those arrows add little.

The dialog lists the relationship types it found (here: vpc, subnets, security groups, cluster, db subnet group, and so on) and lets you switch them off. The layout still uses every edge, so boxes stay where they are while you toggle. With vpc hidden:

The request path from the load balancer to the service and the database is now the thing you see first. You can also switch between a top-down and a left-to-right layout.

The feature I use most: drift against the last import

Diagrams are most useful during review, when you want to see what a change does to the architecture, not what the architecture is.

Each time you insert a diagram, the dialog remembers it in your browser as the baseline for that format. Paste the new version of the code, turn on Drift vs last, and the preview colours the difference: added blocks and relationships in green, removed ones in red with a dashed outline.

In the next version of our example, the S3 bucket is gone and an ElastiCache Redis cluster and a second ECS service for background workers have arrived:

For a PR, this is the picture I actually want in the description. It answers "what does this change touch?" faster than scrolling a terraform plan, and it works before anyone has run a plan at all.

Why "without a plugin" matters

This approach has a few properties that are easy to overlook until you need them:

No credentials, no state. The parser reads text. It never talks to AWS, never needs a backend, and does not care whether the code has been applied.
No terraform init. No providers are downloaded and no working directory is needed, so it works on a branch you just checked out, on a snippet from a code review, or on a module you are only evaluating.
It runs in your browser. The parsing and layout happen client-side, so your resource names and CIDR ranges are not sent to a server to build the picture.
Licensing-neutral. Nothing is run or redistributed; the HCL is only parsed as text, so the same flow works for Terraform and OpenTofu code alike.

Limits worth knowing

A static parser is honest about what it cannot know:

count and for_each are not expanded. A resource with count = 3 is one box, which is usually what you want in an architecture view anyway.
A module is one box. Its internals are not followed; if you want them, paste the module's own files and import them as a separate diagram.
Values that only exist after apply (IDs, ARNs, DNS names) are not resolved.
The local name of a resource (the app in aws_lb.app) is not shown on the card; the card uses the type, the name attribute and key attributes instead. Variables, modules and outputs therefore show their kind rather than their name.
Load file takes one file at a time. For a whole folder, concatenate first (cat *.tf) and paste the result.
Generate from Code is part of the Pro plan.

Automating it

The same converter is available outside the editor. With a personal API token, POST https://api.letdraw.com/api-v1/documents/from-code with the Terraform text in the body creates the diagram in a workspace, and the diagram_from_code tool does the same for AI coding assistants over MCP. That makes it possible to regenerate the diagram from CI whenever the infrastructure folder changes. (Icons and the drift view are editor features; the API returns the plain diagram.)

Try it

Open letdraw.com and choose Generate from Code.
Paste a .tf file (or a few concatenated) and look at the live preview.
Turn on Add icons, hide the relationships that add noise, and insert.
Next time the code changes, paste the new version and turn on Drift vs last.

The diagram you can generate in thirty seconds from the code under review will always beat the beautiful one in the wiki that nobody trusts. Give it a try on your own repo, and tell me which provider or block type it should understand better.

Stop Redrawing Your Architecture: YAML, SQL, Terraform and EXPLAIN Plans to Diagrams in One Paste

Adnan H. Çelik — Tue, 06 Oct 2026 14:46:04 +0000

I have a confession: for years, the most out-of-date file in every repo I worked on was docs/architecture.png.

It was never anyone's fault. The diagram was correct on the day someone drew it. Then a service got split, a Redis cache appeared, a queue was added, a table gained a foreign key. Nobody wanted to open a drawing tool and push boxes around again, so the picture slowly turned into fiction, and new teammates learned the system by reading YAML instead.

The thing is, the YAML (and the SQL, and the HCL) already describes the system. The picture is just a different view of the same source of truth. That is the idea behind LetDraw: a hand-drawn whiteboard that can read the files engineers already have and draw them for you, as real, editable shapes.

This post is a practical tour. No marketing slides, just six things I actually use it for:

Kubernetes YAML to diagram
Docker Compose to diagram
SQL to ER diagram
Terraform diagram, online
Postgres EXPLAIN visualizer
Hand-drawn ER diagrams

The one feature everything else builds on: Generate from Code
All of the conversions below go through a single dialog called Generate from Code. You paste text (or load a file) and it:

auto-detects the format, so you never pick "Kubernetes" or "SQL" from a dropdown,
shows a live preview before anything touches your canvas,
inserts normal shapes, not an image. Every box, label and arrow is editable afterwards.

That last point is the whole difference between a diagram generator and a diagram renderer. A rendered image is read-only; you either accept the layout or you go back and fight the source. Here, auto-layout gets you most of the way, and then you nudge a box, add a sticky note, or highlight the risky path like you would on any whiteboard.

A few other options show up across all formats:

Add icons stamps recognisable product icons (Postgres, Redis, Kubernetes, AWS, Azure, GCP and more) onto the boxes.
Drift vs last compares the current import with your previous one: added resources in green, removed ones in red. Great for change reviews.
Layout direction (top-down or left-right) and which relationship types to show.

Honest note up front: drawing by hand, templates, shape libraries and PNG/SVG/PDF export are free. Generate from Code is part of the Pro plan ($5/month). I will point out where that matters.

1. Kubernetes YAML to diagram

Here is a trimmed version of a typical service:

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: shop
spec:
  selector:
    app: web
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: shop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: shop/web:1.4
          envFrom:
            - configMapRef:
                name: web-config

Paste that (multi-document YAML is fine, or load the whole file) and you get a cluster diagram where:

resources are grouped by namespace, so the layout mirrors how you think about the cluster instead of one flat soup of nodes,
Services are linked to the workloads they select, based on the actual label selectors,
workloads are linked to the ConfigMaps, Secrets and PersistentVolumeClaims they mount.

It understands Deployments, StatefulSets, Services, Ingress, ConfigMaps, Secrets, volume claims and RBAC objects, so a permissions review can start from a picture of which service accounts are bound to which roles.

Helm users: paste the output of helm template to see the rendered resources, or paste a Chart.yaml to see the chart and its subchart dependencies.

Where this has saved me the most time:

Manifest reviews. Import the manifests from a PR, then turn on Drift vs last to see exactly which resources were added or removed.
Onboarding. New engineers get the platform as one picture before they open forty YAML files.
Incidents. The cluster diagram sits next to the runbook, with comments pinned on the parts that broke.

More detail: Kubernetes diagram tool.

2. Docker Compose to diagram

Compose files are even simpler, which makes them a perfect first try:

services:
  web:
    image: nginx
    depends_on: [api]
  api:
    image: app:latest
    depends_on: [db, redis]
  db:
    image: postgres:16
  redis:
    image: redis:7

Paste it and four services appear, laid out and connected. With Add icons on, the Postgres service becomes a database cylinder, Redis gets its own icon, and the depends_on edges become arrows that route around boxes instead of through them (LetDraw has an obstacle-avoiding "smart" connector, which is a small detail until you have tried to read a diagram where every arrow crosses three boxes).

Same dialog, same auto-detection as Kubernetes, so you do not need to tell it which one you pasted.

The workflow I recommend: keep the generated diagram next to the compose file, and when the stack changes, re-import and check Drift vs last rather than editing the drawing by hand. The picture stays right by construction, not by discipline.

There is a longer walkthrough on the blog: Docker Compose diagram, from docker-compose.yml to clean architecture.

3. SQL to ER diagram

This is the one my backend friends ask about most. Take your migrations or a schema-only dump:

CREATE TABLE users (
  id    uuid PRIMARY KEY,
  email text UNIQUE NOT NULL,
  name  text
);

CREATE TABLE orders (
  id         uuid PRIMARY KEY,
  user_id    uuid NOT NULL REFERENCES users(id),
  total      numeric(10,2),
  created_at timestamptz DEFAULT now()
);

CREATE TABLE order_items (
  order_id uuid NOT NULL REFERENCES orders(id),
  qty      int
);

Paste it and you get:

every table as a grid with a header and one row per column, type next to name,
PK and FK markers, with long types shortened (timestamptz, varchar) so tables stay compact,
relationships drawn between tables, and you choose the style: plain line, arrow, smart routed connector, or crow's foot notation.

The crow's foot cardinality is not a guess. It is inferred from the foreign key column itself: a NOT NULL FK means "exactly one" on the parent side, a nullable one means "zero or one", and a UNIQUE FK turns one-to-many into one-to-one.

It handles Postgres, MySQL and standard SQL, including quoted names, schema prefixes (public.users), IF NOT EXISTS, inline REFERENCES and separate FOREIGN KEY constraints. Comments are ignored, so you can paste a migration file as-is.

Two details I like:

While the generated ERD is unchanged, Diagram to Code gives it back as Mermaid erDiagram code. Handy if your docs live in Markdown.
Everything is normal shapes, so you can sketch the proposed tables for a new feature right next to the current schema and argue about it with comments on the relationships.

More: SQL to ER diagram.

4. Terraform diagram, online

No CLI to install, no graph tooling, no cloud credentials. Paste HCL into the browser:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "app" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

resource "aws_security_group" "web" {
  vpc_id = aws_vpc.main.id
}

resource "aws_instance" "web" {
  instance_type          = "t3.micro"
  subnet_id              = aws_subnet.app.id
  vpc_security_group_ids = [aws_security_group.web.id]
}

LetDraw reads resource, data, module, variable and output blocks and turns references into arrows: aws_vpc.main.id, var.region, depends_on. Each arrow is labelled with the attribute that created the link (vpc_id, subnet_id), which is exactly the information you want during a review.

Each resource becomes a card with its type, its name and a couple of key settings (CIDR block, instance type). Resources are grouped by provider, so a multi-cloud estate keeps AWS, Azure and GCP in separate frames, and modules, variables and outputs get their own frames too.

Use cases where it pays off:

Architecture reviews: show reviewers what the code actually builds instead of walking them through file after file.
Change reviews: paste the new version, turn on Drift vs last, and see added and removed resources and links.
Dependency checks: before renaming a variable or a module output, see who reads it.

More: Terraform diagram generator.

5. Postgres EXPLAIN visualizer

This one is not an architecture diagram at all, and it is the feature that surprised people the most when I showed it around.

Run your query with a JSON plan:

EXPLAIN (ANALYZE, FORMAT JSON)
SELECT *
FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.created_at > now() - interval '7 days'
ORDER BY o.created_at DESC;

Paste the JSON output and you get a tree, one box per plan node, showing the node type, the table, index or function it touches, cost, rows and, with ANALYZE, the time in milliseconds across all loops.

The important part is the heat map. Postgres reports cost and time cumulatively, which is why the root node of every plan looks like the most expensive one. The visualizer subtracts each node's children and colours by self time, from green through amber to red. So the node that actually hurts (that sequential scan on orders, say) lights up red, instead of the Sort at the top that merely inherits its children's time.

It also takes MySQL EXPLAIN FORMAT=JSON, showing each table with its access type, cost and rows.

And it runs in your browser, so the plan, your table names and your query text stay on your machine. That matters when the query touches production schemas you would rather not paste into a random website.

Things I now do with it:

Before and after an index: both plans on one canvas, and you can see which node turned from red to green.
Code review: attach the plan of a new query to the PR so reviewers see its cost, not just its SQL.
Post-mortems: export the heat-mapped tree as SVG and put the culprit right in the write-up.

More: EXPLAIN plan visualizer.

6. Hand-drawn ER diagrams (and why the sketchy look is a feature)

Everything above is generated, but LetDraw is first and foremost a whiteboard, and the default style is hand-drawn.

I used to think that was purely aesthetic. It is not. A sketchy diagram signals "this is a draft, please argue with it." People comment on a hand-drawn ERD in a design review far more freely than on a polished one that looks final. That is exactly the conversation you want before the first migration is written.

What makes it usable for real data modelling rather than doodling:

Crow's foot cardinality as native arrowheads: one, zero or one, zero or many, one or many. You pick them on the arrow ends, no hand-drawn markers to keep aligned.
A Database Schema template to start from, plus SQL import when you want the real thing.
A Sketchiness setting (Clean, Sketch, Scribble), so the same ERD can go from whiteboard draft to clean documentation without redrawing it.
Mermaid ER import and export, and AI drafts from a plain-language description.

Drawing ER diagrams by hand, with all of the above, is free.

More: ER diagram tool.

What sets it apart (from a developer's point of view)

I have used a lot of diagram tools. Most fall into one of two camps: pretty whiteboards that know nothing about your stack, or diagrams-as-code renderers that know your stack but give you a read-only image. LetDraw sits in the middle, and that is the point:

Code in, editable shapes out. Kubernetes, Helm, Compose, Terraform, SQL, EXPLAIN plans, Graphviz DOT, PlantUML, OpenAPI, git log, Mermaid and D2 all become real shapes you can move and annotate.
And back to code. Diagram to Code exports Mermaid or D2, so a diagram can live in your repo and be reviewed like code.
Local-first and private. No install, works offline, drawings stay in your browser, no third-party tracking. Live collaboration and shared snapshots are end-to-end encrypted in the browser with AES-GCM.
Real-time collaboration with live cursors, roles, and comments you can pin to any point on the canvas, not just to a shape.
Embeds that do not go stale. Drop a snippet into a README or wiki for a live, read-only view, instead of a PNG someone must remember to re-export.
Automation. There is a REST API and an MCP server, so CI jobs and AI agents can create and update diagrams, too.
AI that is not a paywall trap. Every plan gets a few free AI requests; after that you can bring your own provider key (BYOK) for unlimited use.
Self-hosting is available on the Enterprise plan, for teams that need diagrams to stay inside their own network.

Why DevOps and software teams should care

Diagrams are not documentation for documentation's sake. They are how we:

onboard people faster than any wiki page,
review infrastructure and schema changes without reading every file,
explain incidents to people who were not on the call,
argue productively about trade-offs before code exists. The reason teams skip them is cost: drawing is slow, and keeping drawings current is slower. If the diagram can be regenerated from the same YAML, HCL or SQL that runs in production, that cost mostly disappears, and the diagram stops being fiction.

Try it in two minutes

Open letdraw.com. No sign-up needed to start drawing.
Grab a docker-compose.yml, a Kubernetes manifest, some CREATE TABLE statements or an EXPLAIN (FORMAT JSON) output from your own project.
Open Generate from Code, paste, and look at the preview.
Insert it, move a few boxes, and share the link with a teammate. If you try it on a real project, I would love to hear what broke, what surprised you, and which format you want next. Drop a comment below.