Tools mentioned in this article
Open the browser-based tool while you read and try the workflow immediately.
That Familiar Moment of Dread
“Hey, didn’t we add a RabbitMQ instance in front of this API server?”
When a junior engineer casually pointed this out during a meeting, my blood ran cold. The infrastructure diagram floating in our internal Wiki was staring back at me, proudly displaying a ‘Last Updated’ timestamp from six months ago.
Let’s be honest, infrastructure evolves constantly. We add a Redis cache here, a reverse proxy there. But going through the sheer pain of opening a heavy graphical drawing tool, dragging little square icons around, painfully aligning arrows, exporting the PNG, and uploading it to the Wiki… It’s just too much friction. Everyone thinks, “I’ll definitely update the diagram later,” and of course, nobody ever does.
Craving ‘Diagram as Code’
To kill this “forever outdated diagram” issue, I turned to Mermaid.js. The idea of ‘Diagram as Code’ is a dream for developers: you write some text, commit it to git, and a beautiful diagram magically appears.
But doing this locally had its quirks. Trying to write complex nested graphs (like an EC2 instance inside a VPC inside an AWS Cloud region) required learning syntax that wasn’t exactly intuitive. I’d write the code, wait for a PR preview to build, only to find out my arrows were pointing backwards.
Seeing It Build As You Type
“I just want to type the text and watch the diagram smoothly build itself on the other side of my screen in real-time.”
That entirely selfish desire is what birthed this “Infrastructure Diagram Builder.”
My biggest rule while building it was zero server communication. Infrastructure layouts are basically the blueprints to the company vault. There is absolutely no way I’d want you pasting that into a tool that sends data to some random server (even if it’s my random server). So, I forced the entire rendering pipeline into local, browser-side JavaScript.
If you’re currently dreading an infrastructure documentation update, try typing some code into this tool. Seeing the diagram snap into place gives you this weird, satisfying feeling of supreme architectural power.
In the End, What Lasts Is “Lightness”
Building this drove home something I’d half-known: diagrams go stale not because the syntax is hard, but because updating feels like a chore. The moment a single ritual gets in the way — launch a heavy tool, rearrange icons, export, re-upload — people choose “later.” And later never comes.
So the priority for this tool became “open it the instant you think of it, and fix it in five seconds.” Keep node names short, draw only the main flows, and split into separate diagrams once you pass ten nodes. That level of looseness is what actually lasts. A messy diagram that stays current beats a perfect one that’s six months old — the current one is the one that saves future-you.
FAQ
Do I have to know Mermaid syntax to use it?
No. You add nodes and connections one at a time and the Mermaid code is generated for you behind the scenes. You can produce a diagram without knowing the syntax, and copy the generated code straight into a GitHub README.
Is the infrastructure I enter sent anywhere?
No. Rendering happens entirely in your local browser. Because sending a company’s infrastructure layout to an external server felt too risky, it was designed from the start to never leave your machine.
Does the diagram render in a GitHub README?
Yes. GitHub renders Mermaid flowcharts natively, so you can manage your architecture diagram as text instead of an image file — and track changes in pull requests just like code.
How should I draw a large diagram with many nodes?
Rather than cramming everything into one, split by role (network / application / data / monitoring). Around ten nodes is a good threshold to split. Not over-packing is what keeps the diagram maintainable over time.