Structurizr Cloud Shuts Down on 30 September: Get Your Model Out First

Structurizr's cloud service is end of life. Their end-of-life page lists "Structurizr cloud service (no replacement)" alongside Lite, the CLI and the on-premises installation, all replaced by the new consolidated tooling. Per their end-of-life announcement, workspaces went read-only on 1 July 2026, remaining monthly subscriptions were stopped the same day, and the service shuts down on 30 September 2026. That announcement sits behind Patreon, so check the dates against it yourself before you plan around them.

Read-only is not the emergency. The emergency is what read-only hides: the tools you would use to extract your workspace are part of the service that is closing. The DSL tab in the workspace editor, the export link on your dashboard, the web API. All of them are the cloud service. On 1 October there is no tab to click.

So the first decision is not which tool you move to. It is getting a file onto your disk. That is a copy and a paste per workspace, and it commits you to nothing. Choosing a destination is neither of those things.

Get your model out

Do this part first, before you read anything below it.

Your workspaces are read-only, not invisible. Structurizr's cloud service FAQ says of read-only workspaces: "You can still view the workspace content (via the UI and web API) but no changes can be made." Everything below works today.

If you authored in DSL and pushed with the CLI, you may already be done. Your workspace.dsl is in Git. Open it and check it is current. The one thing to look for: any layout you nudged by hand in the browser diagram editor lives in the cloud copy, not in your DSL. If that matters to you, take the JSON export in step 2 as well.

If you authored in the browser, or through the Workspace API, your model exists only in Structurizr's database. In this order:

The DSL. Structurizr's own advice to existing users is to convert to the DSL. From their workspace editor help page: "A DSL representation of your workspace (excluding documentation) can be found on the DSL tab." The workspace editor itself was discontinued in February 2022 but remains reachable at a URL of the form https://structurizr.com/workspace/XXXXX/workspace-editor, where XXXXX is your workspace ID. Open it, click the DSL tab, copy everything, save it as workspace.dsl.

Note the parenthesis in their sentence. The DSL representation excludes documentation. If you wrote documentation or ADRs into the workspace rather than pointing !docs and !adrs at Markdown files in a repository, the DSL tab will not give them back to you.
The JSON. Structurizr's migration guidance points you at the "export your workspaces" link at the top of the page. That produces workspace.json. Take it even if you already have DSL. It is the format Structurizr's own playground and local both accept, and local looks for workspace.dsl and workspace.json in that order.
Anything the two files miss. Documentation written in the workspace, images you uploaded, decision records with their status history. Open the workspace in the UI and copy what you care about into Markdown while the UI still exists.
Commit both files to a repository. Not a laptop folder. A repository, next to the code they describe, where the next person will find them.

Repeat per workspace. If you have twelve of them, do them in one sitting rather than promising yourself you will come back.

One thing I could not establish: Structurizr has not published, anywhere I could find, whether workspace data is deleted on 30 September or merely made unreachable. Do not assume you can ask for it back in October. Do not assume you cannot, either. Get the files.

Where to put it

Four honest options. They suit different teams, and three of them are not archyl.

Option 1: Structurizr's own tooling

This is the right answer for more teams than any vendor blog will tell you, and it should be the first thing you price.

Structurizr is not going away. The cloud service is. Their EOL page maps the old products onto new ones: Lite is replaced by local, the CLI by pull / push / export, and the on-premises installation by server. If you are on Lite or the CLI today, you also have a migration in front of you, just a much smaller one.

local is described on their docs as "the free and open source local command provides a way to view diagrams and modify their layout". It runs on your machine, bound to localhost. Their quickstart is two commands: docker pull structurizr/structurizr, then docker run -it --rm -p 8080:8080 -v PATH:/usr/local/structurizr structurizr/structurizr local. Point it at a directory holding your workspace.dsl, open http://localhost:8080, edit the file, refresh the browser.
The playground is their suggestion for occasional use: upload workspace.dsl or workspace.json, look at the diagrams, close the tab.
server is the one that replaces what the cloud service did for you, publishing workspaces to a wider audience. It has an open core that is free if you build it from source, with file-system storage, Lucene search and no authentication. The prebuilt binaries add SAML, role-based access control, private sharing tokens, S3 and Azure Blob storage, Elasticsearch and an admin API, and require a license: £300 per month for 1 to 20 unique users, £600 for 21 to 50, £900 for 51 to 100, billed annually. Their definition of a unique user counts anyone who views a diagram, including through an iframe or an image embed, not just editors.

Who this suits: teams whose model is already DSL in Git, whose readers are engineers, and whose main use of the cloud service was rendering. You keep your DSL exactly as it is, you keep the deployment and dynamic views that our own importer drops, and the tooling is written by the person who invented the C4 model. If that is you, stop reading here and go run the Docker command.

Who it does not suit: teams who need a hundred non-engineers to browse the diagrams without you operating a server, and teams for whom £300 a month for twenty viewers reads worse than a per-editor SaaS price. And one more, which is the argument the rest of this post rests on: self-hosting preserves your model, it does not maintain it. The workspace that went stale in the cloud will go stale in local too. Nobody re-runs the DSL when the code changes.

Option 2: keep the DSL in the repo and stop paying for a tool

The most underrated option, and the cheapest.

workspace.dsl in Git, reviewed in pull requests like anything else, rendered on demand when somebody actually needs a picture. local renders it in a container. So does the playground. If you would rather move off Structurizr's syntax entirely, LikeC4 is MIT-licensed, authored as .c4 files in your repository, and publishes through a Vite plugin, React components or web components, so diagrams can be embedded in a docs site you already run.

Who this suits: teams where the audience for the diagrams is a handful of engineers who can read a DSL, and where the honest answer to "how often does anyone open this?" is "at onboarding and during incidents". You lose nothing you were using and your recurring cost is zero.

Who it does not suit: anyone whose diagrams are read by people who will not clone a repository. Which, if you were paying for the cloud service, may be exactly why you were paying for it.

Option 3: another hosted C4 tool

If the cloud service was doing a job for you, replacing it with another hosted tool is a reasonable move, and you should look at more than one.

IcePanel is the closest like-for-like: a visual-first C4 tool with a hosted service and a free tier of five editors, unlimited viewers and up to 100 model objects, with paid plans starting at $40 per editor per month billed annually. Their own comparison against Structurizr says "model objects can be imported from Structurizr, Backstage, and a REST API". I could not find the accepted file format documented on the pages I could reach, so before you commit, upload the exact file you extracted in the section above and confirm what survives. That advice applies to every tool in this post, including ours.

Who this suits: teams who want a drag-and-drop editor and viewers who are not engineers.

Who it does not suit: teams who moved to Structurizr because the model was text. Giving up architecture-as-code to escape a cloud shutdown is a strange trade, and you will feel it the first time you want to diff a change.

Option 4: archyl

We built a Structurizr DSL importer, so this is the option I know best and the one you should read most skeptically.

Bring workspace.dsl, not workspace.json. Archyl parses Structurizr DSL text. There is no workspace-JSON path. If the export link gave you JSON and nothing else, see the section below before you try.

Open a project, choose Structurizr DSL in the import modal, upload the .dsl file or paste it. What comes across: person and softwareSystem at the top level, nested container and component, names and descriptions, technology strings on containers and components and on relationships, comma-separated tags, group blocks at any depth flattened into group:<name> tags, and relationships declared anywhere in the file including inside element bodies. Container and relationship types are inferred from your technology and label strings. External systems are picked up from the External System or External tag. The importer is tested against Simon Brown's own Big Bank sample workspace.

What does not come across, which matters more:

All layout and styling. views, configuration and styles blocks are skipped. Archyl auto-lays out the diagram instead. Manual layout is one of the things Structurizr sells, so this is the thing your old tool was best at and you are giving it up.
!docs and !adrs. The directives are skipped. Archyl has ADRs and documentation; the Structurizr importer does not fill them.
!include. Multi-file workspaces have to be flattened before import, or the included content simply is not there.
Deployment environments, deployment nodes and infrastructure nodes. Not imported.

The importer prints most of that back to you as a warning list on the import result screen, in the source file's own terms:

line 42: 'views' block is not supported and was skipped
line 7: directive '!docs' is not supported and was skipped

Two caveats on that, because a list you can trust is worth more than a list that flatters us. First, deployment environments and nodes are skipped: archyl models the static structure and not deployment topology. The parser names them in the warning list with their line number, so a deploymentEnvironment "Live" block arrives as a line you can read rather than something you find out later. Second, a warning tells you what the parser refused; it does not tell you the import was otherwise perfect. Read the model afterwards.

The one argument for paying for this rather than running local: archyl re-checks the model against the repository and scores the gap, so a model that stops matching the code says so instead of quietly becoming wrong. That is the drift score, it is deterministic, and it runs without an AI call. If your Structurizr workspace was accurate and current on the day the cloud went read-only, you do not need this and I would not try to sell it to you. If it was eighteen months stale, the tool was never the problem, and moving it somewhere else will not fix it.

Two things you should hold against us. The free Developer plan caps a project at 100 model objects, so a workspace with fifty systems and their containers will not fit in it; and archyl is cloud-first, with self-hosting only on the Custom tier. The reason Structurizr gave for closing the cloud service, in the same announcement that carries the dates, was that engineering teams have been reluctant to publish architecture diagrams to the cloud and usage had steadily declined. If that describes your security team, option 1 is a better fit than we are, and you should not spend two weeks discovering it in procurement.

If all you have is a JSON file

The export link on your dashboard gives you workspace.json, and it is the file most people will end up holding. Where it lands:

Structurizr local and the playground read it directly. Nothing to convert.
Archyl does not. Get the DSL from the DSL tab instead, and do it before 30 September. If the workspace was authored through the Workspace API and the DSL tab does not give you something usable, two fallbacks: connect the repository and let AI discovery propose the model from the code, or point a coding agent at the JSON and have it write the model through the MCP server, which is the recipe here.
Anywhere else: ask before you migrate, not after.

Choosing, in one paragraph

If your model is already DSL in Git and your readers are engineers, run local and spend the money you saved elsewhere. If you need a shareable, access-controlled instance and can carry the license, server is the closest thing to what the cloud service was doing for you. If you want a visual editor and non-technical viewers, look at IcePanel. If the workspace you just exported was already out of date, and it is out of date because updating it by hand was somebody's fourth priority, then the tool is not what needs replacing, and that is the case archyl is arguing.

Whichever of those you pick: get the files out first. The tab disappears with the service.

More on the mechanics: importing Structurizr, LikeC4 and IcePanel projects, the Structurizr migration page, and a 2026 comparison of C4 tools. If you are new to the model itself, start with the C4 model and architecture drift.