SchematIaC Docs I spent four years trying to see infrastructure. SchematIaC is the editor I kept restarting.
Four years ago I won first place in NVIDIA’s Omniverse developer competition for MetaCloudExplorer. I worked with graphic artist Andy Green to put my Azure estate in a 3D space. Andy turned the Azure icons into models. I wrote an Omniverse extension that grouped, aggregated, and let you walk the cloud in ways a portal never will.
NVIDIA wrote it up as Meet the Omnivore.
It was cool. It was not useful. Omniverse sat behind a walled garden: special hardware, special software, Python, an extension install that only people who already lived in that world would attempt. I had built a prototype to learn Omniverse. The unfinished idea was bigger than the prototype. I did not just want to see the cloud. I wanted to edit it.
The first editor that did not survive the company
After the win I teamed up with grand-prize winner Yizhou Zhou and started Digital Bot Lab. One of the first things we tried was VisualIAC — a visual Terraform editor at the provider layer. That was my world. Yizhou’s was robotics. He helped us get seed money from MiraclePlus to work on digital twins for robots, and VisualIAC stalled.
I spent that stretch on industrial digital twins in Azure and Omniverse. Yizhou went on to NVIDIA. Digital Bot Lab did not last long. The time was not wasted — Azure IoT, twins, a sharp collaborator — but the IaC editor was still sitting on the bench. The idea was right. The vehicle was not.
Blast radius is the actual job
I wanted to go back to VisualIAC. I also had a full-time job. Instead I spent a few years doing cloud infrastructure for a friend, all in Bicep. That is where the language stopped being abstract.
Terraform and Bicep are not programming languages in the usual sense. They are declarations: you describe what you want, and an engine builds it. Terraform keeps a state file and a plan of exactly what will change. Bicep rides Microsoft’s ARM engine into Azure. HashiCorp’s IaC intro covers the textbook version.
At scale they stop being simple. A resource reads a workspace value that lands in a variable that is interpolated into a name that is passed into a module that pins a provider. Change one string and you need a plan to see what else moved. Cloud stops being “a thing you click in a portal” and becomes code: branches, reviews, releases.
The real job is the blast radius. Text is a terrible map of that graph. I have always been a visual person. A schematic lets me hold more of the system at once than a file tree ever will.
Why I finally built it
Writing software used to be the tax that killed side projects. Trial and error, keeping the whole program in your head, deciding the app was not worth the years. Once models started writing the tedious parts with me, the apps I had been carrying around became buildable.
VisualIAC came back off the shelf. Some ideas you cannot drop. MetaCloudExplorer was supposed to become an editor, not a fly-through. “Visual IaC” sounded like a viewer. I wanted a schematic for infrastructure as code. Schematic + IaC: SchematIaC. Say it like “schematic” with an ack — skee-MAT-ee-ack.
I spent the last few months building it. It is done enough to put in front of people.
The visualizers that already exist
I am not the first person who wanted a picture of Terraform. The category is crowded. Most of it either draws a graph you cannot touch, or it takes the keyboard away and generates the HCL for you.
terraform graph and Graphviz are the official answer. You pipe DOT into dot and get a PNG. It is a dependency graph of the engine, not of the file you are editing. On a real root it is spaghetti. You screenshot it, pin it in a wiki, and it is stale the next commit.
Blast Radius made that graph interactive — d3, pan, prune-to-selection. It is the tool that taught a lot of us to think blast radius. It also wants Python, Graphviz, and an initialized directory, and it serves a browser tab. You look, then you go back to the editor to change anything. The project has not kept pace with modern Terraform.
Rover is the one I still see recommended. Docker, copy the tree into a container, run a plan, open localhost:9000. Overview, map, graph. Useful. It is still a plan visualizer. You leave VS Code, you need a terraform binary and enough backend access to plan, and the picture is of what the engine would do — not a surface you can rewire.
Inframap and Terraform Visual sit in the same bucket: HCL or plan-JSON in, a cleaner diagram out. CLI or a browser. Read-only. Fine for a PR comment. Not a place you work.
Pluralith and Overmind go further into the pipeline. They run terraform plan for you, draw the change, sometimes cost or blast radius against live infra, and paste it onto the PR. That is a review tool. It wants CI, a plan, often an account. The diagram lives next to the pull request, not next to the file.
Then there is the other takeover: Brainboard. Design the architecture on their canvas, emit Terraform. That is a real product, and it is the opposite of what I wanted. Your repo becomes an export. Comments, module boundaries, the ugly-but-true history of the files — gone, or constantly regenerated. Onboarding a teammate means onboarding the SaaS. The source of truth moved.
The pattern is the same in both camps. The read-only tools make you leave the editor — Docker, Graphviz, a plan, a browser — and come back to type. The design-first tools make you leave the files — their canvas is canonical, HCL is a build artifact. Either way the visualization owns a step that used to be yours.
I wanted the picture in the editor, over the files that already exist, with an edit that writes those files back. No plan required to see the schematic. No second source of truth. That is the gap SchematIaC is for.
A schematic over your real files
SchematIaC is a VS Code canvas over the Terraform or Bicep you already have. Blocks become nodes. Properties become rows. References become wires. You edit the drawing; it edits the files. There is no shadow language and no generated-only DSL. Save writes the same .tf / .bicep you would have typed.
A one-resource sample does not show that. A two-tier Azure template with every NIC and route table lit at once does not either — that is a hairball, not a first impression. I opened the public Palo Alto templates and started with the small one: vpc_sample. A VPC, one subnet, the variables that feed them. The drawing is four or five nodes and a handful of wires you can actually count.
That subnet is not “a resource with two strings.” Its VPC is the other node. Its CIDR comes off a variable. In the file that is easy to skim past. On the canvas it is two wires you can hold.
resource "aws_subnet" "NewPublicSubnet" {
vpc_id = aws_vpc.main.id
cidr_block = var.PublicCIDR_Block
}
Click vpc_id and the rest of the drawing dims. The lineage stays lit — the VPC node, and nothing else — so the blast radius is a path, not a grep.
The canvas evaluates locally. The CIDR reads as 10.0.0.0/24, not the expression. A mark says when a value was computed rather than typed, and it is honest when something cannot be known before a real deploy.
When it gets dense
The same repo’s azure_two_tier_sample is the hairball: resource group, storage, public IPs, NSG, every NIC and route. That is a real Tuesday file. It is a terrible first screenshot. Open it after vpc_sample and the move is the same — click a row, everything else dims — except now you need it.
Compare still works when you put two canvases side by side. Show Diffs does the same job against git: a branch, a tag, the merge base of a PR. Added, removed, changed. Removed blocks stay as ghosts so you see the hole, not just a missing box.
The tree, then the wiring
For the shape of a whole sample repo, Folder Overview reads every .tf under terraform-templates — nothing is evaluated — into one picture: a card per folder (aws_two_tier, azure_two_tier_sample, one-click-multi-cloud, …), wires for who calls whom as a local module. From there you open the detailed canvas. The Azure cluster in terraform-azure-samples/simple-cluster is the same move when you want modules as boxes with ports.
That is the whole trick. The schematic is not a picture of the code. It is the code, viewed as the graph it always was. Drag a wire or edit a value; the review is the exact one-line diff; comments and alignment stay put; nothing is written until you Save.
The rest of the editor answers the questions that make you open plan in the first place. Upgrade Preview on a registry module or a provider paints what a newer version would do here — inputs you set that vanish, arguments the target docs no longer list — worded as “docs say…”, never “this will break.” Analyze lists the re-wirings the graph already argues for. Every change is staged. Your code never leaves the machine.
The agent does not replace the schematic. The schematic is what the agent uses
A lot of the people who will read this already let an agent touch their Terraform. Cursor, Claude Code, Copilot — the model writes the HCL, you review the diff, you hope it understood the blast radius. That is the same job the canvas is for. SchematIaC is not another agent. It does not compete with yours. It is the tool your agent should call when the files get too wide for a context window.
SchematIaC ships a Model Context Protocol server. Claude Code, Cursor, Claude Desktop, or any other MCP client gets the same local engine the canvas uses. The agent can read the graph, ask what a value actually resolves to, trace a lineage, preview a module or provider upgrade against this canvas, and get a validated diff for a proposed change. Still on your machine. No terraform or bicep binary. Your files are never uploaded.
The important half: it never writes a file. Every edit tool returns a diff and the new file text. The agent’s own host applies it, or you do. Same rule as the canvas — nothing reaches disk until you say so.
That is the enhancement. An agent grepping HCL is guessing. An agent with the schematic knows that vpc_id is a wire to aws_vpc.main, that a tfvars line is what the subnet actually gets, that changing one variable fans out across the two-tier sample the way Figure 3 shows. It can propose a surgical one-line rewrite instead of regenerating a file. You still review. You just review a change that was computed against the graph, not against a guess.
Command palette: SchematIaC: Copy MCP Setup for AI Agents. Pick the client, paste once, reload. After that you talk to the agent in English. You do not paste JSON on every question.
What it deliberately is not
It is not a new IaC language. HCL and Bicep stay the source of truth.
It is not a 3D or VR toy. It runs in VS Code, where the files already are.
It is not a replacement for terraform plan or an ARM what-if. Those still own the remote world. SchematIaC answers a smaller, sharper question: what on this canvas would move.
It is not an AI agent. Your agent writes and applies. SchematIaC is the ground truth that agent can ask.
Some features are Terraform-first — upgrade preview, simulated workspaces, copy between canvases. Bicep is first-class for parse, edit, and git diffs. That split is honest, not a roadmap slide.
Try it on a folder you already have
MetaCloudExplorer was the visualization. VisualIAC was the first editor attempt. SchematIaC is the one you can install.
Open schematiac.com, get the VS Code extension, and point it at a folder you already trust. The schematic is the point: see the blast radius before you type it.