Diagraff exists to turn an idea into a picture. Mermaid is how we do that in 2026 because it is the best format available — not because we are married to it. This page is the argument, including the part where we tried the alternative twice and threw it away twice.
The syntax is settled. Getting a picture out of it — quickly, at a price you control, on infrastructure you trust — is not.
Mermaid won. It is in GitHub, in Notion, in Obsidian, in every docs pipeline worth the name, and a model that has read the public internet can write it without being taught. That argument is over, and we are not reopening it with a proprietary syntax nobody's model has seen.
What is still unsolved is everything around the format. Who pays for the inference. Whether the render is a round-trip to somebody's queue or a repaint in the tab you already have open. Whether your library is portable, or a hostage with an export button. Whether you can run the whole thing yourself when your employer decides diagrams containing the architecture cannot leave the building.
Those are delivery questions, and they are where a product can still be meaningfully better than its competitors. So that is where we compete: your key, your box, your data, no metering of a bill you already paid.
A format-agnostic product needs a format-agnostic spine, and this one has had it from the beginning. Nothing in the storage layer, the API or the agent interface hard-codes Mermaid; they all read from one small registry.
scope, declared on the very next
line of the same table, does have one. The database would accept another
engine's rows today.That is the whole honest claim about pluggability: the shape of the thing does not fight a second engine. It is not the same as saying a second engine is a config flag away, and we are not going to say that.
This is the part a competitor would leave out. PlantUML, D2, Graphviz and
Ditaa have all shipped in this codebase, through a Kroki sidecar and a
server-side /api/render endpoint. Both times, we took them out
again.
Multi-language templates, Kroki auto-detection, per-language example seeding. bfe864b
Non-Mermaid support pulled out after eight days, deferred to a future that would arrive. f508f60
Full multi-engine support back: PlantUML, D2, Graphviz, Ditaa. 44b9292
Mermaid-only again. The Kroki sidecar and /api/render
deleted outright — and a regression test added so the decision has
to be argued with, not drifted past. d7b2517
Every non-Mermaid engine needed a server to draw the picture. That single fact undid the product: a render queue to run and pay for, a sidecar to patch, your diagram source leaving the browser to be rendered elsewhere, and a self-hoster suddenly deploying two services instead of one. The engines we could add were exactly the engines that broke the promises we actually sell.
The second removal went further than the first. It deleted the render endpoint, and it added a test asserting that the languages API returns Mermaid and nothing else. There is also a boot-time routine that deletes seeded examples for any engine no longer supported, so a database that once held PlantUML samples cleans itself up. The codebase now defends the decision without anyone remembering to.
A third attempt is not a matter of enthusiasm. It needs an engine that renders in the browser, so the "no server round-trip" promise survives contact with it; a library small enough that loading it does not tax the people who never asked for it; and enough people asking for that specific engine to justify the second renderer's permanent cost. Meet those three and the registry is waiting. Miss any one and we will keep shipping one excellent renderer instead of several mediocre ones.
Read the three constraints above and the roadmap writes itself. The work is not "add more syntaxes". It is everything that makes the picture cheap, fast, and yours:
Cheap means the model bill stays between you and your provider. Bring an Anthropic, OpenAI or OpenRouter key and it skips our AI quota entirely, because metering something we did not pay for would be a tax, not a product. Self-hosting costs nothing to us at all.
Fast means the render never leaves your machine, so editing is a repaint rather than a request — and it stays that way as we grow, which is precisely the constraint that keeps disqualifying server-rendered engines.
Yours means MIT for the whole application, plain-text diagrams you can walk out with, one-click import from the incumbent, and an MCP server so your coding agent works the library directly instead of through a browser.
If a better format than Mermaid arrives and it can draw in a browser, the registry is where it goes and your existing diagrams do not move. That is the promise. Not that we support everything — that we are not trapped.