Draw it. Explain it. Change it. Run it.

Keystone covers the whole life of your architecture: one model of every system, the stories that explain it, the changes you propose, and a simulator to test them.

Request access Why Keystone?

The Keystone diagram editor during a simulation, with Postgres saturated and a message trace open — The diagram editor, paused mid-simulation.

Draw it: one shared model

Keystone stores objects (apps, stores, queues, people) and the connections between them. A diagram is a view onto that model, so the same object can sit on every diagram and never drift.

Nest objects as deep as your system goes, and open any one to look inside.
Start with C4-style types, then add your own names, icons, colours and shapes.
Give each object an owning team, tags, technologies and a status: live, future, deprecated or removed.
Pick any object and see what it needs, and what breaks if it goes down.
Press Ctrl/Cmd+K to jump to any object, connection, diagram or flow.

Keystone object panel for Postgres showing its type, parent and status — One Postgres, one set of facts, whichever diagram you open it from.

See the whole landscape at once

The Landscape Map lays every system out on one board, with stores drawn as cylinders and boundaries on the floor. Filter by type or tag, then drill into any object.

It's the page to send a new hire on day one.

Keystone Landscape Map showing the whole landscape as an isometric board — The Landscape Map.

Explain it: flows that play back

A flow walks one request through the system, step by step. Play it like a slideshow, with alternate and parallel paths for the "what if it fails?" branches, and link to subflows for the details.

Flows use the same objects as your diagrams. Export one as Mermaid, code or plain text for your docs.

Keystone flow playback on step 3 of 6 — Flow playback, step 3 of 6.

Explain why: comments and decisions

Comments pin to the object, connection or spot on the canvas they're about, with threads and @-mentions. Mark one as a question, an idea or an inaccuracy.

Decision records keep the why, with a status timeline and links to diagrams, drafts and other decisions. Approved ones lock.

Keystone decision records timeline: ADR-1 approved, ADR-2 rejected, ADR-3 in progress — Decision records, each with its status.

Change it: drafts and snapshots

Propose a change as a draft. Everyone sees it in place, with a list of every change and who proposed it. When it merges, Keystone checks for conflicts with anything that changed in the meantime.

Snapshots freeze the whole landscape, by hand or on a schedule. Browse any one, or roll back to it.

Keystone draft editor with 3 changes and a Merge button — A draft that adds a search service, ready to merge.

Run it: simulation

This is the part other architecture tools don't have. Put small rules on objects, a few lines of JavaScript each, then send a steady stream, a spike or a ramp of traffic through the model.

Put a rule on a technology, like Postgres, and every Postgres gets it.
Nodes change colour and fill their meters as the run plays.
Every dropped message has a trace: each rule it met, in order.
Same seed, same run. Everyone replays the same failure.

Keystone sends traffic through your model and shows where it breaks.

Built to live inside your company

Single sign-on: SAML and OIDC, with IdP groups mapped to roles. Passwords as a fallback.
Roles and access: Admin, editor and viewer, access per landscape, and objects only their team can edit.
API and webhooks: A REST API with scoped keys, and signed webhooks when the model changes.
Import and export: Import YAML or JSON. Export PNG, SVG, PDF, JSON, CSV, Markdown, HTML or llms.txt.
Share links: Read-only links with an optional password. Viewers can even run the simulations.
Feed your AI tools: Export the landscape as llms.txt or Markdown so an assistant reads your real architecture.
Audit log: Who changed what, person or API key. Export it as CSV.

How self-hosting works