Building Strata: A Visual Infrastructure Builder for Cloud Teams

Cloud infrastructure has a funny way of becoming invisible right when you need to understand it most.

At first, the setup is simple: a few services, a database, maybe a queue, maybe a storage bucket. Then the product grows. A staging environment appears. A shortcut becomes a production dependency. Someone adds a security group rule during a launch. Someone else updates Terraform but forgets about a console change. Eventually, the actual infrastructure, the code that describes it, and the team's mental model of it are no longer the same thing.

That is the problem we built Strata to explore.

Strata is a visual infrastructure builder for cloud teams. The goal is not to replace infrastructure-as-code, cloud consoles, or platform engineering discipline. The goal is to make the shape of the system easier to see, easier to reason about, and easier to move between diagrams, cloud state, and code.

Why We Built It

AWS and other cloud platforms are powerful, but they are not always easy to visualize.

Resources live across regions, accounts, services, and deployment tools. One part of the system may be described in Terraform. Another may be sitting in CloudFormation. Another may have been created manually. Another may exist only as JSON output from a tool, export, scan, or API response.

That gets hard to track when a team needs to answer practical questions:

• What resources do we actually have?
• How are they connected?
• Does production match the code?
• What changed since the last deploy?
• What rules should this architecture follow?
• Can we turn this diagram back into usable infrastructure code?

Most teams already have pieces of the answer. They have Terraform, JSON, cloud APIs, diagrams, tickets, docs, and people who remember why something was done. Strata is our attempt to bring those pieces into one visual workflow.

The Core Idea

Strata treats infrastructure as a graph.

Instead of starting with a blank document or a static diagram, Strata models cloud resources as typed nodes and relationships. A database can connect to an application service. A VPC can contain subnets. A load balancer can route traffic to compute. A resource can carry metadata, rules, estimates, and export details.

That graph can then move in both directions:

• Build visually. Start with a canvas and map out the system you want.
• Extract from code. Import infrastructure definitions and turn them into a graph.
• Extract from data. Bring in JSON or other structured resource data.
• Compare drift. Look for differences between what the code says and what exists.
• Convert back to code. Export the graph into infrastructure scaffolding, including Terraform-oriented output.

This is the part that matters to us: the diagram should not be a dead artifact. It should stay close to the infrastructure it represents.

Why Visualization Matters

Infrastructure problems are often communication problems wearing a technical jacket.

If a developer, founder, agency, or operations lead cannot see how the resources fit together, every change feels riskier. Security reviews take longer. Estimates get fuzzy. Hand-offs become fragile. Onboarding a new developer requires a guided tour of every little decision that never made it into the docs.

A visual map gives the team a shared object to discuss.

Not a whiteboard that gets stale. Not a screenshot from a cloud console. Not a perfect enterprise architecture diagram that no one wants to update. Something closer to the working system.

That is especially useful when infrastructure is spread across AWS and other cloud providers, or when a project has grown through a mix of code, console work, and emergency fixes.

Where MCP Fits

One of the more interesting parts of Strata is the local MCP server.

The idea is that a local tool can help agents and developers work with infrastructure in a safer, more structured way. Instead of asking an AI assistant to guess what your architecture looks like from a paragraph, the MCP server can expose Strata's infrastructure model, rules, validation, import, and export workflows.

In practical terms, that opens the door to commands like:

• List the available cloud services and resource types.
• Import infrastructure from code or structured data.
• Build an infrastructure map.
• Check the architecture against project rules.
• Compare expected infrastructure with discovered resources.
• Generate Terraform scaffolding from the graph.

That does not mean the tool should blindly deploy anything. It means the assistant can work against a more explicit model instead of loose context.

For us, that is the difference between "draw me an AWS diagram" and "use this typed resource graph, validate it against these rules, and generate the next draft of infrastructure code."

What Works Today

Strata is still early, but the direction is clear.

The current public work focuses on the visual infrastructure canvas, resource modeling, import/export direction, and the MCP-backed workflow. The repository is public here:

makedirectory/strata

The larger goal is a loop:

1. Start with infrastructure code, JSON, cloud resource data, or a blank canvas.
2. Convert that into a visual graph.
3. Check it against rules.
4. Compare it against reality when possible.
5. Export the next version back to code.

That loop matters because infrastructure rarely stays in one format for long. Teams need to inspect it, explain it, change it, and ship it.

What Comes Next

The backend is where this gets much more interesting.

Once we release more of the backend workflow, Strata should be able to do more with discovery, drift comparison, validation, and code generation. The vision is not just a prettier diagram. It is a tool that helps teams understand what exists, what changed, what is missing, and what should happen next.

There is a lot more to come once we release the backend.

For now, Strata is a practical experiment in a problem we keep running into: cloud infrastructure is too important to be trapped in scattered code, screenshots, and memory.

We built Strata because we wanted a better way to see the system, reason about it, and turn that understanding back into working infrastructure.

If you are thinking through AWS, Terraform, cloud drift, infrastructure maps, or MCP-powered developer workflows, take a look at the repo or reach out. This is exactly the kind of workflow problem we like solving.