Should I vibe code
Hosted Mermaid diagrams with visual editing and collaboration
Mermaid is MIT and already renders in your README. The subscription is a login screen around a Markdown feature.
?
Their verdict, the not published price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Start with the awkward fact: Mermaid is MIT-licensed, and it is already inside the tools you use. GitHub renders a ```mermaid fence in any README or issue comment, GitLab and Notion do the same, Obsidian and VS Code ship it, and mermaid.live — the free editor — is itself an MIT repo you can deploy this afternoon. So the honest question is not whether an agent can rebuild this; it is whether you need to build anything at all. A textarea, a debounced render and a download button is an evening, and for most people even that is redundant. What the commercial tier sells is the part that is not Mermaid: a team's diagram library with accounts and permissions, Confluence and Jira plugins, an AI prompt box, and presentations. Those are real, and none of them are the renderer. Keep your diagrams as .mmd files in the repo and the whole question dissolves.
What actually breaks
not "if". the specific failures.
- Nothing, locally — which is the entire point, and why this is one of the safest builds on the site
- Mermaid's own major versions, which move syntax and defaults; an unpinned renderer turns a diagram that parsed last year into a red error box in your docs
- A hosted renderer fed diagram text by strangers, where labels containing HTML and remote image references become XSS and SSRF unless you set securityLevel and a render timeout
- Exported SVG on someone else's machine, because the font you rendered with is not installed there
- The half that is not Mermaid at all — accounts, shared libraries, who-can-see-which-diagram — which is where every hour of the project actually goes
Is that you?
the verdict is a default, not a law
- The diagrams document code, in which case commit the .mmd next to it and let GitHub do the rendering for free
- A textarea, a live preview and an SVG export is the entire brief
- Rendering happens locally or in CI, so a diagram of your infrastructure never leaves the network
- You pin the Mermaid version and treat an upgrade as a change that needs testing
- What you actually wanted was a shared, permissioned diagram library for a team — that is a collaboration product with a very different verdict
- Your team lives in Confluence and Jira and the plugins were the reason you were paying
- You will host a public renderer that accepts arbitrary diagram source without sandboxing it
If you build it anyway
the checklist, then the prompt that enforces it
- Check whether you need to build anything. If the diagrams belong to a repo, a fenced mermaid block in Markdown already renders on GitHub, GitLab and most editors, at no cost and with no service to run.
- If you do build, wrap the official renderer. Never reimplement parsing or layout — that is decades of other people's work and the only reason the output looks right.
- Pin the Mermaid major version and record which one you are on. Syntax and defaults have changed across majors, and a docs build that suddenly renders error boxes is a bad way to learn that.
- Add a CI step that parses every .mmd in the repo and fails the build on an error, so a broken diagram is caught by the pipeline rather than by a reader six months later.
- If it is hosted and takes input from anyone but you, set securityLevel to strict or sandbox, strip HTML from labels, block remote image and font fetches, cap input size and time out the render.
- Embed or subset fonts on SVG export. A diagram that only looks right on your laptop is a diagram you cannot put in a document.
Before writing any code for a Mermaid-based diagram tool, work through these in order. 1. First question, out loud: do I need this at all? Mermaid is MIT and already renders inside GitHub, GitLab, Notion, Obsidian and VS Code. If my diagrams live in a repo, tell me to commit a fenced mermaid block and stop there. 2. If I still want a tool, wrap the official mermaid package. Do not write a parser and do not write a layout engine. Refuse if I ask, and explain what would be reimplemented. 3. Pin the mermaid major version explicitly in the manifest and write the version into the README. Major upgrades have changed syntax and defaults; treat an upgrade as a code change that needs a test run, not a dependency bump. 4. Build export before the editor: SVG first, then PDF, then PNG. Subset or embed fonts so an export renders identically on a machine that does not have my fonts. 5. Build a CI command that renders every .mmd file in the repo and exits non-zero on a parse error. Do this before any UI work, so a diagram that stops parsing fails a build. 6. Default to running locally. My architecture diagrams describe my infrastructure and should not be posted to a service by default. 7. If I later ask to host it for other people, stop and cover these before the feature: securityLevel set to strict or sandbox, HTML in node labels escaped rather than rendered, remote image and font fetching disabled, an input size cap and a render timeout. A public renderer accepting arbitrary diagram text is the only way this tool can hurt anyone, and the two historical holes are exactly HTML labels and remote fetches. 8. Keep rendering deterministic: same input, same bytes out, so diffs are readable. 9. Deliberately out of scope unless I ask for them: accounts, shared team libraries, permissions, comments and an AI prompt-to-diagram box. Those four are the commercial product, none of them are the renderer, and each turns an evening into an operation.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
You want the parts that are not Mermaid: a shared team library with permissions, the Confluence and Jira plugins, SSO, or the AI prompt box. That is a genuine product and worth money to some teams. Note that the pricing page is now sales-led and publishes no readable number, so get a figure in writing before you commit, and confirm that export of your own diagram source is included — the source is the only thing you would be trying to take with you.
There is nothing to exit, and that is the reason to do it this way. Your diagrams are .mmd files in your repository. They render on GitHub with no tool at all, in mermaid.live, in your editor, and in Kroki. Delete whatever wrapper you built and every diagram still works.
The MIT renderer the whole category is built on, and the one GitHub already runs on your README.
The editor behind mermaid.live, MIT-licensed and self-hostable — very close to the hosted product's free tier.
One HTTP service that renders Mermaid, PlantUML, Graphviz and a dozen other diagram languages.
Questions
Mermaid is free and open source. What is Mermaid Chart actually selling?
Hosting and the things around the diagram: accounts, a shared team library with permissions, version history, Confluence and Jira plugins, presentations and an AI prompt-to-diagram box. The renderer is the same MIT package you can install yourself. It is a reasonable business — it just is not the part that was hard.
Do I need to build anything at all?
Probably not. If the diagrams belong to code, put a fenced mermaid block in the Markdown and GitHub renders it. If you want a scratchpad, mermaid.live is free and its source is MIT. Building your own wrapper is a nice evening, but be clear it is a preference and not a necessity.
Is there any way to get this wrong?
Two, and both are avoidable. Leaving the Mermaid version unpinned means a future major can break diagrams already committed to your docs. And if you host a renderer that accepts diagram text from other people, set securityLevel and block remote fetches — HTML in labels and remote image references are the two places diagram renderers have historically leaked.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Layout is the hard part, and Graphviz solved it in the nineties. You are paying €7 a month for a textarea.
Diagram-as-code is a solved problem. Keeping the canvas and the code from drifting apart is not.
“Read-only” is not “harmless”. ReadOnlyAccess includes s3:GetObject, and your weekend diagram tool now holds it.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice