Looking for a Structurizr cloud alternative
Structurizr's hosted service reaches end of life on 30 September 2026. If you have been keeping an architecture model as text and rendering it as a set of nested views, this page is an honest account of what flowgo replaces and what it does not. The short of it: flowgo derives no views from a model. What it keeps is one structure you go on editing — every box opens into the level below it, in one plain-text file.
What flowgo does not replace
Start here, because it is the part that decides whether the rest is worth reading. Structurizr's central idea is one model, many views: you describe software systems, containers and components once in the DSL, and the tool derives a context diagram, a container diagram and component diagrams from that single definition, keeping them consistent by construction.
flowgo does not do that. There is no model layer, no element typing, no automatic view generation, no consistency checking between views, and no C4 DSL. A flowgo map is a drawing whose source happens to be text. If deriving several views from one typed model is the thing you cannot lose, flowgo is not your migration target — look at self-hosting Structurizr, or at IcePanel, Ilograph or Likec4.
What flowgo does do
The part of the Structurizr workflow flowgo keeps is the one most tools drop: levels that stay connected. In flowgo every box can contain its own map, so a system diagram, the internals of one service, and the internals of one component inside it are the same file — you drill in by double-clicking a box and walk back out through a breadcrumb.
There is a worked example in the gallery:
an arc42 Building Block View three levels deep, with its
.flowgo source printed underneath it.
The comparison, straight
| Structurizr | flowgo | |
|---|---|---|
| Source of truth | DSL / JSON workspace | Plain-text .flowgo file |
| Typed model (system / container / component) | Yes | No |
| Several views derived from one model | Yes | No |
| Nested levels in one artefact | Yes | Yes |
| Edit in a GUI and have it write back to the source | Layout only | Everything |
| Diffable in a pull request | Yes | Yes |
| Editable by an AI agent | By writing DSL | By writing the file, or over MCP |
| Hosted option | Ends 30 Sep 2026; self-hosting remains | flowgo-map.com, or run the binary yourself |
| Licence | Open source core, commercial hosting | AGPL-3.0 core, commercial hosting |
Where flowgo is genuinely better
One place, and it is the one that shows up daily: the round trip. A flowgo map is edited in the browser and the edit rewrites the text file — so a colleague who will not learn a DSL can still move a box, and the change lands in the repo as a readable diff. A DSL-first tool asks everyone who touches the diagram to learn the DSL first. That is a fair trade when the model is the point; it is a tax when someone just needs to add a service.
The same property is what makes an agent-drawn map useful rather than disposable. Your agent writes the file, you drag the three boxes it got wrong, and the file it wrote is the file you corrected.
Migrating
There is no automated importer, and pretending otherwise would waste your afternoon. Export your workspaces from Structurizr while the service is still up — that is worth doing today regardless of where you land — and if you try flowgo, rebuild one view by hand first to see whether losing the model layer costs you anything you actually use.
Structurizr's own migration guidance covers the playground, local and self-hosted server routes. Read it before you shop.
Try it
No account, nothing to install. Open a canvas, draw two boxes, double-click one and draw inside it.
Or from an agent: one create_map call against
https://flowgo-map.com/api/mcp returns a shareable URL —
see the docs.
flowgo-map.com is an alpha service and says so. If the model layer matters to you, flowgo is the wrong tool and this page has said so twice.