Structurizr Cloud is gone. Here's how to keep your model — and get a visual editor.
If you keep an architecture model in Structurizr, you've probably already seen this: the cloud service shuts down on 30 September 2026, and there is no replacement — Structurizr's own end-of-life notice says so in as many words.1 If your workspace lives only there, this post is about getting it out safely, what your real options are, and — since we build a tool in this space — where CRAYON-C4 does and doesn't fit.
What's actually happening
The Structurizr cloud service — the hosted workspace product at structurizr.com where you'd store and render a DSL-authored workspace — is being discontinued. Structurizr Lite (a free, local/self-hosted renderer) and the on-prem structurizr/onpremises Docker image both continue. The DSL language itself, the open-source parser, and the whole docs-as-code idea behind it are not going anywhere. What's ending is specifically the cloud-hosted place your workspace has been living.
That distinction matters for what you do next: this is a hosting problem, not a data-format problem. Your workspace.dsl — or the JSON your workspace compiles to — is a plain text file you own. Nothing about the shutdown makes that file less valid; it just stops having a server to live on.
Get your workspace out, today
Before anything else: export your workspace now, while the service is still up. Structurizr's own docs cover the export mechanics for both the web UI and the CLI/API — if you set your workspace up years ago and don't remember which, check whichever you used to push changes to it originally, since export is usually the mirror of that.
One thing worth checking if you manage your workspace through the API or CLI rather than the DSL directly: confirm you can pull back a .dsl file, not only the compiled JSON. If your setup only ever produces JSON, say so wherever you're discussing this — a JSON importer is a reasonable thing for tools in this space (including ours) to add, and it's easier to justify building with a real example in hand than a hypothetical one.
Your options, roughly in order of effort
1. Stay on Structurizr, just not the cloud. Structurizr Lite runs locally (a small self-hosted server, genuinely free) and renders the same DSL you already have. If your team's workflow is DSL-first — the model lives in a text file, gets reviewed in pull requests, and you don't need a visual editor — this is the least disruptive move. You lose the cloud's hosting and sharing convenience, keep everything else.
2. Move to another hosted visual tool. IcePanel is the other name that comes up here — a polished, cloud-hosted C4 tool with its own strengths (and its own pricing model, worth checking against your team size).
3. Import into CRAYON-C4. This is what we build, so take it as one option among the above rather than the answer: CRAYON reads a Structurizr DSL workspace directly — free, on every tier, no account required to try it — and adds a visual editor, F4 behavioral flows, and deployment views with replica counts on top of the same C4 model. It also exports back to DSL at any point, so picking it isn't a one-way door out of the Structurizr ecosystem.
If you pick CRAYON: what actually happens
Open Projects → New project → From file, pick your .dsl file, and CRAYON parses and converts it — element names, hierarchy, relationships (with technology and description), groups, deployment trees, and any custom styles all come across. If a dynamic view is in there, it becomes an F4 behavioral flow: one lane per element, one activity per step.
Not everything makes the trip, and the honest list is worth reading before you commit to anything: filtered/custom/image views, themes, !include/workspace extends, hierarchical identifiers, and enterprise boundaries (which import flat) have no equivalent on our side and are reported, not silently dropped. The full Structurizr DSL docs list every construct on both sides, with worked examples and downloadable sample files.
Here's a live CRAYON-C4 model, for reference — not literally your workspace, but the shape of what an import gives you to work with:
The comparison, stated plainly rather than as a sales pitch, is in a dedicated page — including when Structurizr (or Structurizr Lite specifically) is still the better call for your team.
The window is longer than the deadline
Whichever way you go, do the export this week. "Structurizr alternative" search volume doesn't stop on October 1st — teams migrate over weeks, not a single weekend — so there's no rush to decide everything today. There is a reason to get the file out today, though: a service that's shutting down is not where you want to discover, on September 29th, that your last export was from two years ago.
If you land on CRAYON and hit a wall — a DSL construct that didn't come across, a workspace shape we haven't seen — the support page reaches us directly, and "here's a workspace that didn't import cleanly" is exactly the kind of report that becomes a fix.
Footnotes
-
Structurizr end-of-life notice: docs.structurizr.com/eol. ↩