Strata: A Diagram That Can Tell You It Is Wrong

We wrote about Strata when it was a visual infrastructure builder — a canvas for seeing the shape of a cloud system when the console, the code, and the team's mental model had stopped agreeing with each other.

It has moved on since, in one particular direction: away from being a drawing and towards being a model you can ask questions of.

An architecture diagram is a picture. Pictures cannot be wrong, because they do not claim anything checkable. A typed graph of your infrastructure can be wrong, and that turns out to be the entire value.

Strata is Apache-2.0 and public.

Three clouds and the code you already have

The catalog now spans AWS, Google Cloud, and Azure, with typed relationships — contains, routes_to, invokes, peers_with — rather than arrows that mean whatever the reader assumes.

More usefully, you do not have to draw any of it. Strata imports what you already have:

• CloudFormation, JSON or YAML
• terraform show -json, for AWS, GCP, or Azure
• Azure ARM templates
• Live cloud state, through provider discovery APIs

All of it lands in the same graph, and the graph exports back out as infrastructure-as-code. A diagram derived from your real state has a property a hand-drawn one never has: when it disagrees with reality, one of them is wrong, and you can find out which.

The engines are the product

Sitting on top of the graph is a set of analysis engines, and they are the reason the typed model was worth building:

Validation with one-click autofix. Findings come with deterministic fixes — detect and apply, not a suggestion to go and read a documentation page.

True internet-reachability. This is the one worth pausing on. Most tools answer a topology question: is there a line between these two things? Strata evaluates whether something is actually reachable from the internet, taking subnets, route tables, and security-group ports into account. Those are different questions, and the gap between them is where security incidents live. A resource can look isolated in every diagram in the company and still answer the phone.

Explain & Clean. An account review producing cost, risk, and a safe-cleanup checklist — for the situation where somebody inherited an account and needs to know what can be deleted without a story that ends badly.

Cross-cloud migration mapping. Service equivalence across providers, which turns "what would it take to move this" from a workshop into a diff.

A change receipt. An audit of what changed between any two versions of the graph — drift, cost, and findings. The artifact you want when someone asks what happened between Tuesday and Friday.

Plus tag tinting and filtering, canvas annotations, and a Diagram-as-Code DSL with a YAML round-trip, so the graph can live in version control alongside everything else.

Everything is derived from a registry

The core architectural idea has not changed and has paid for itself repeatedly: everything visual is derived from a data registry, not hardcoded.

Adding a service to the catalog is one entry. No UI changes, no new component, no special case in the renderer. Categories, config forms, relationship rules, and edge styling all read from the same data.

This is the difference between a system that grows and one that accumulates. The version where each service gets bespoke UI code looks identical for the first twenty services and becomes unmaintainable somewhere around the hundredth.

Pure engines, and why an agent can drive it

Read through src/aws/ and a word keeps appearing in the file comments: pure. Overlays, reachability, the account review, cross-cloud mapping, autofix, the change receipt, tags, annotations, and the DSL are all pure transforms — no DOM, no network, no credentials.

That was not tidiness for its own sake. It is what makes the MCP server a thin wrapper rather than a parallel implementation. An agent connected to Strata calls validate_architecture, evaluate_reachability, import_iac, estimate_cost, review_account, map_to_cloud, apply_autofix, change_receipt — the same functions the interface calls, producing the same answers.

npm run mcp

The alternative — an API layer that reimplements the analysis for programmatic callers — is how you end up with a tool that gives one answer in the UI and a different one over the wire, and no way to say which is right.

What we learned: the ambient credential chain

The most instructive bug in the project was not a bug when it was written.

Live discovery runs server-side. With no credentials in the request, it falls back to the server process's default credential chain — environment variables, shared profile, SSO, instance role. On a single-user local run that is exactly right: they are your own credentials, and asking you to paste them into a box you are already authenticated for would be theatre.

Host that same code on a shared deployment and the ambient chain becomes the operator's account. Any visitor could enumerate it.

The fix is a flag — NEXT_PUBLIC_STRATA_HOSTED=1, set at build and runtime — that disables the ambient fallback entirely. Each user then brings their own credentials, sent over HTTPS for a single scan, held in memory only: never written to disk, never logged, never returned, never saved into a diagram. The documentation asks for temporary read-only credentials, and the credential-free paste-an-export path stays available regardless.

The lesson generalises well beyond this project. The same code is safe or unsafe depending on who the process belongs to. Convenience that is correct on your laptop can be a vulnerability the moment there is a second user, and nothing about the code changes in between. It is worth asking of any system you inherit: which of these conveniences assume a single trusted operator, and is that still true?

Diagrams save in your browser

Saved diagrams persist in localStorage. No account, no database, no external infrastructure, and it runs on a read-only serverless host. Export and import JSON to move a diagram between browsers.

There is a server tier in the codebase for a future durable backend, and it is deliberately not on the path today. A tool people are evaluating should not require them to create an account before they can find out whether it is useful.

Trying it

npm install
npm run dev

The product serves at / and the documentation at /docs, split into a user guide and an architecture section for anyone who wants to read how it works internally. The hosted version is at strata.mk-dir.com.

Start by importing something real. A blank canvas tells you nothing; your own account with the reachability overlay on tends to start a conversation.

If what you actually need is someone to look at your cloud setup and tell you plainly what is exposed, what it costs, and what would happen in an outage, that is what an assessment is for.