O Structurizr Cloud Encerra em 30 de Setembro: Tire Seu Modelo de Lá Primeiro

O serviço cloud do Structurizr chegou ao fim de vida. A página de end of life deles lista "Structurizr cloud service (no replacement)" ao lado do Lite, da CLI e da instalação on-premises, todos substituídos pelo novo tooling consolidado. Segundo o anúncio de fim de vida, os workspaces ficaram somente leitura em 1º de julho de 2026, as assinaturas mensais restantes foram encerradas no mesmo dia, e o serviço é desligado em 30 de setembro de 2026. Esse anúncio está atrás do Patreon, então confira as datas por conta própria antes de fazer qualquer planejamento em cima delas.

Somente leitura não é a emergência. A emergência é o que o somente leitura esconde: as ferramentas que você usaria para extrair seu workspace fazem parte do serviço que está fechando. A aba DSL no editor de workspace, o link de exportação no seu dashboard, a web API. Tudo isso é o serviço cloud. Em 1º de outubro não há aba nenhuma para clicar.

Então a primeira decisão não é para qual ferramenta você vai migrar. É colocar um arquivo no seu disco. Isso é um copiar e colar por workspace, e não te compromete com nada. Escolher um destino não é nem uma coisa nem outra.

Tire seu modelo de lá

Faça esta parte primeiro, antes de ler qualquer coisa que venha depois.

Seus workspaces estão somente leitura, não invisíveis. O FAQ do serviço cloud do Structurizr diz sobre workspaces em somente leitura: "You can still view the workspace content (via the UI and web API) but no changes can be made" — você ainda pode visualizar o conteúdo do workspace (pela UI e pela web API), mas nenhuma alteração pode ser feita. Tudo o que vem abaixo funciona hoje.

Se você escrevia em DSL e dava push com a CLI, talvez já esteja pronto. Seu workspace.dsl está no Git. Abra e confira se está atualizado. A única coisa a procurar: qualquer layout que você ajustou na mão no editor de diagramas do navegador vive na cópia da nuvem, não no seu DSL. Se isso importa para você, pegue também a exportação JSON do passo 2.

Se você escrevia no navegador, ou pela Workspace API, seu modelo existe apenas no banco de dados do Structurizr. Nesta ordem:

O DSL. O conselho que o próprio Structurizr dá aos usuários atuais é converter para o DSL. Da página de ajuda do editor de workspace deles: "A DSL representation of your workspace (excluding documentation) can be found on the DSL tab" — uma representação DSL do seu workspace (excluindo a documentação) pode ser encontrada na aba DSL. O editor de workspace em si foi descontinuado em fevereiro de 2022, mas continua acessível em uma URL no formato https://structurizr.com/workspace/XXXXX/workspace-editor, onde XXXXX é o ID do seu workspace. Abra, clique na aba DSL, copie tudo, salve como workspace.dsl.

Repare no parêntese na frase deles. A representação DSL exclui a documentação. Se você escreveu documentação ou ADRs dentro do workspace em vez de apontar !docs e !adrs para arquivos Markdown em um repository, a aba DSL não vai devolvê-los para você.
O JSON. As orientações de migração do Structurizr apontam para o link "export your workspaces" no topo da página. Ele produz workspace.json. Pegue mesmo que você já tenha o DSL. É o formato que tanto o playground do Structurizr quanto o local aceitam, e o local procura por workspace.dsl e workspace.json nessa ordem.
Tudo o que esses dois arquivos deixam passar. Documentação escrita dentro do workspace, imagens que você subiu, registros de decisão com seu histórico de status. Abra o workspace na UI e copie para Markdown o que te importa enquanto a UI ainda existe.
Faça commit dos dois arquivos em um repository. Não em uma pasta no notebook. Em um repository, ao lado do código que eles descrevem, onde a próxima pessoa vai encontrá-los.

Repita para cada workspace. Se você tem doze deles, faça todos de uma vez em vez de prometer a si mesmo que vai voltar depois.

Uma coisa que não consegui estabelecer: o Structurizr não publicou, em nenhum lugar que eu tenha encontrado, se os dados dos workspaces serão apagados em 30 de setembro ou apenas ficarão inacessíveis. Não presuma que você vai poder pedi-los de volta em outubro. E não presuma o contrário também. Pegue os arquivos.

Onde colocar

Quatro opções honestas. Elas servem a times diferentes, e três delas não são o archyl.

Opção 1: o próprio tooling do Structurizr

Esta é a resposta certa para mais times do que qualquer blog de fornecedor vai te dizer, e deveria ser a primeira coisa que você orça.

O Structurizr não está indo embora. O serviço cloud está. A página de EOL deles mapeia os produtos antigos nos novos: o Lite é substituído pelo local, a CLI por pull / push / export, e a instalação on-premises pelo server. Se você está no Lite ou na CLI hoje, você também tem uma migração pela frente, só que bem menor.

O local é descrito na documentação deles assim: "the free and open source local command provides a way to view diagrams and modify their layout" — o comando local, gratuito e open source, oferece uma forma de visualizar diagramas e modificar seu layout. Ele roda na sua máquina, atrelado ao localhost. O quickstart deles são dois comandos: docker pull structurizr/structurizr, e depois docker run -it --rm -p 8080:8080 -v PATH:/usr/local/structurizr structurizr/structurizr local. Aponte para um diretório que contenha seu workspace.dsl, abra http://localhost:8080, edite o arquivo, atualize o navegador.
O playground é a sugestão deles para uso ocasional: suba workspace.dsl ou workspace.json, olhe os diagramas, feche a aba.
O server é o que substitui o que o serviço cloud fazia por você: publicar workspaces para um público mais amplo. Ele tem um núcleo aberto que é gratuito se você compilar a partir do código-fonte, com armazenamento em sistema de arquivos, busca com Lucene e sem autenticação. Os binários pré-compilados acrescentam SAML, controle de acesso baseado em papéis, tokens de compartilhamento privados, armazenamento em S3 e Azure Blob, Elasticsearch e uma API de administração, e exigem licença: £300 por mês para 1 a 20 usuários únicos, £600 para 21 a 50, £900 para 51 a 100, cobrados anualmente. A definição de usuário único deles conta qualquer pessoa que visualize um diagrama, inclusive por um iframe ou uma imagem embutida, não só quem edita.

Para quem serve: para times cujo modelo já é DSL no Git, cujos leitores são engenheiros, e cujo uso principal do serviço cloud era a renderização. Você mantém seu DSL exatamente como está, mantém as views de deployment e as dinâmicas que o nosso próprio importador descarta, e o tooling é escrito pela pessoa que inventou o modelo C4. Se esse é o seu caso, pare de ler aqui e vá rodar o comando do Docker.

Para quem não serve: para times que precisam que cem pessoas não técnicas naveguem pelos diagramas sem que você opere um servidor, e para times para quem £300 por mês por vinte leitores soa pior do que um preço SaaS por editor. E mais uma, que é o argumento em que o resto deste post se apoia: self-hosting preserva o seu modelo, não o mantém. O workspace que ficou desatualizado na nuvem vai ficar desatualizado no local também. Ninguém roda o DSL de novo quando o código muda.

Opção 2: deixar o DSL no repo e parar de pagar por uma ferramenta

A opção mais subestimada, e a mais barata.

workspace.dsl no Git, revisado em pull requests como qualquer outra coisa, renderizado sob demanda quando alguém realmente precisa de uma imagem. O local renderiza em um container. O playground também. Se você preferir sair de vez da sintaxe do Structurizr, o LikeC4 tem licença MIT, é escrito como arquivos .c4 no seu repository e publica através de um plugin do Vite, componentes React ou web components, de modo que os diagramas podem ser embutidos em um site de documentação que você já mantém.

Para quem serve: para times em que a audiência dos diagramas é um punhado de engenheiros que sabem ler um DSL, e em que a resposta honesta para "com que frequência alguém abre isso?" é "no onboarding e durante incidentes". Você não perde nada do que estava usando e seu custo recorrente é zero.

Para quem não serve: para qualquer um cujos diagramas são lidos por gente que não vai clonar um repository. O que, se você estava pagando pelo serviço cloud, pode ser exatamente o motivo pelo qual você pagava.

Opção 3: outra ferramenta C4 hospedada

Se o serviço cloud estava resolvendo um problema real para você, substituí-lo por outra ferramenta hospedada é uma jogada razoável, e você deveria olhar mais de uma.

O IcePanel é o substituto mais parecido: uma ferramenta C4 visual em primeiro lugar, com serviço hospedado e um plano gratuito de cinco editores, viewers ilimitados e até 100 objetos de modelo, com planos pagos a partir de $40 por editor por mês, cobrados anualmente. A própria comparação deles com o Structurizr diz "model objects can be imported from Structurizr, Backstage, and a REST API" — objetos de modelo podem ser importados do Structurizr, do Backstage e de uma API REST. Não consegui encontrar o formato de arquivo aceito documentado nas páginas que consegui acessar, então antes de se comprometer, suba exatamente o arquivo que você extraiu na seção acima e confirme o que sobrevive. Esse conselho vale para todas as ferramentas deste post, inclusive a nossa.

Para quem serve: para times que querem um editor de arrastar e soltar e viewers que não são engenheiros.

Para quem não serve: para times que migraram para o Structurizr porque o modelo era texto. Abrir mão de arquitetura como código para escapar do encerramento de um serviço cloud é uma troca estranha, e você vai sentir isso na primeira vez que quiser dar diff em uma mudança.

Opção 4: archyl

Nós construímos um importador de Structurizr DSL, então esta é a opção que eu conheço melhor e a que você deveria ler com mais ceticismo.

Traga o workspace.dsl, não o workspace.json. O archyl faz parsing de texto Structurizr DSL. Não existe caminho para o JSON do workspace. Se o link de exportação te deu só JSON, veja a seção abaixo antes de tentar.

Abra um projeto, escolha Structurizr DSL na modal de importação, suba o arquivo .dsl ou cole o conteúdo. O que atravessa: person e softwareSystem no nível superior, container e component aninhados, nomes e descrições, strings de tecnologia em containers e components e nos relacionamentos, tags separadas por vírgula, blocos group em qualquer profundidade achatados em tags group:<name>, e relacionamentos declarados em qualquer lugar do arquivo, inclusive dentro do corpo dos elementos. Os tipos de container e de relacionamento são inferidos das suas strings de tecnologia e dos seus rótulos. Sistemas externos são identificados pela tag External System ou External. O importador é testado contra o próprio workspace de exemplo Big Bank do Simon Brown.

O que não atravessa, e isso importa mais:

Todo o layout e o estilo. Blocos views, configuration e styles são pulados. O archyl calcula um layout automático no lugar. Layout manual é uma das coisas que o Structurizr vende, então essa é justamente a coisa em que a sua ferramenta antiga era melhor, e você está abrindo mão dela.
!docs e !adrs. As diretivas são puladas. O archyl tem ADRs e documentação; o importador do Structurizr não os preenche.
!include. Workspaces espalhados em vários arquivos precisam ser achatados antes da importação, ou o conteúdo incluído simplesmente não vai estar lá.
Ambientes de deployment, deployment nodes e infrastructure nodes. Não são importados.

O importador devolve a maior parte disso como uma lista de avisos na tela de resultado da importação, nos termos do próprio arquivo de origem:

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

Duas ressalvas sobre isso, porque uma lista em que dá para confiar vale mais do que uma lista que nos favorece. Primeira, ambientes e nodes de deployment são pulados: o archyl modela a estrutura estática, não a topologia de deploy. O parser os nomeia com o número da linha na lista de avisos, então um bloco deploymentEnvironment "Live" chega como uma linha que dá para ler em vez de algo que você descobre depois. Segunda, um aviso te diz o que o parser recusou; ele não te diz que a importação foi perfeita no resto. Leia o modelo depois.

O único argumento para pagar por isso em vez de rodar o local: o archyl reconfere o modelo contra o repository e pontua a distância, de modo que um modelo que deixa de bater com o código avisa, em vez de ficar silenciosamente errado. Isso é o drift score, é determinístico, e roda sem nenhuma chamada de IA. Se o seu workspace do Structurizr estava correto e atualizado no dia em que a nuvem virou somente leitura, você não precisa disso e eu não tentaria te vender. Se ele estava dezoito meses defasado, a ferramenta nunca foi o problema, e movê-lo para outro lugar não vai resolver.

Duas coisas que você deveria contar contra nós. O plano Developer gratuito limita um projeto a 100 objetos de modelo, então um workspace com cinquenta sistemas e seus containers não cabe nele; e o archyl é cloud-first, com self-hosting apenas no tier Custom. O motivo que o Structurizr deu para fechar o serviço cloud, no mesmo anúncio que traz as datas, foi que os times de engenharia têm sido relutantes em publicar diagramas de arquitetura na nuvem e o uso vinha caindo de forma constante. Se isso descreve o seu time de segurança, a opção 1 encaixa melhor do que nós, e você não deveria gastar duas semanas descobrindo isso dentro de um processo de compra.

Se tudo o que você tem é um arquivo JSON

O link de exportação no seu dashboard te dá workspace.json, e é o arquivo que a maioria das pessoas vai acabar tendo em mãos. Onde ele funciona:

O Structurizr local e o playground leem direto. Nada para converter.
O archyl não. Pegue o DSL pela aba DSL, e faça isso antes de 30 de setembro. Se o workspace foi escrito pela Workspace API e a aba DSL não te der algo utilizável, dois planos B: conecte o repository e deixe a descoberta por IA propor o modelo a partir do código, ou aponte um agente de código para o JSON e peça que ele escreva o modelo pelo servidor MCP, que é a receita descrita aqui.
Em qualquer outro lugar: pergunte antes de migrar, não depois.

Escolhendo, em um parágrafo

Se o seu modelo já é DSL no Git e seus leitores são engenheiros, rode o local e gaste em outra coisa o dinheiro que você economizou. Se você precisa de uma instância compartilhável e com controle de acesso e consegue bancar a licença, o server é o mais próximo do que o serviço cloud fazia por você. Se você quer um editor visual e viewers não técnicos, olhe o IcePanel. Se o workspace que você acabou de exportar já estava desatualizado, e está desatualizado porque atualizá-lo na mão era a quarta prioridade de alguém, então não é a ferramenta que precisa ser substituída, e é exatamente esse o argumento do archyl.

Seja qual for a sua escolha: tire os arquivos de lá primeiro. A aba desaparece junto com o serviço.

Mais sobre a mecânica: importando projetos do Structurizr, LikeC4 e IcePanel, a página de migração do Structurizr e uma comparação de ferramentas C4 em 2026. Se o modelo em si é novidade para você, comece pelo modelo C4 e pelo architecture drift.