Structurizr Cloud chiude il 30 settembre: prima tira fuori il tuo modello

Il servizio cloud di Structurizr è a fine vita. La loro pagina di end of life elenca "Structurizr cloud service (no replacement)" accanto a Lite, alla CLI e all'installazione on-premises, tutti sostituiti dal nuovo tooling consolidato. Secondo il loro annuncio di fine vita, i workspace sono passati in sola lettura il 1° luglio 2026, gli abbonamenti mensili rimasti sono stati interrotti lo stesso giorno, e il servizio si spegne il 30 settembre 2026. Quell'annuncio sta dietro Patreon, quindi verifica tu stesso le date prima di costruirci sopra un piano.

La sola lettura non è l'emergenza. L'emergenza è ciò che la sola lettura nasconde: gli strumenti che useresti per estrarre il tuo workspace fanno parte del servizio che chiude. Il tab DSL nell'editor di workspace, il link di export sulla dashboard, la web API. Tutto questo è il servizio cloud. Il 1° ottobre non c'è più nessun tab da cliccare.

Quindi la prima decisione non è verso quale strumento ti sposti. È mettere un file sul tuo disco. È un copia e incolla per workspace, e non ti impegna a niente. Scegliere una destinazione non è né l'una né l'altra cosa.

Tira fuori il tuo modello

Fai prima questa parte, prima di leggere qualunque cosa venga dopo.

I tuoi workspace sono in sola lettura, non invisibili. La FAQ del servizio cloud di Structurizr dice a proposito dei workspace in sola lettura: "You can still view the workspace content (via the UI and web API) but no changes can be made" — puoi ancora vedere il contenuto del workspace (tramite la UI e la web API) ma non è possibile fare modifiche. Tutto quello che segue funziona oggi.

Se scrivevi in DSL e facevi push con la CLI, potresti aver già finito. Il tuo workspace.dsl è in Git. Aprilo e verifica che sia aggiornato. L'unica cosa da controllare: qualsiasi layout che hai sistemato a mano nell'editor di diagrammi del browser vive nella copia in cloud, non nel tuo DSL. Se la cosa ti interessa, prenditi anche l'export JSON del passo 2.

Se scrivevi nel browser, o attraverso la Workspace API, il tuo modello esiste solo nel database di Structurizr. In questo ordine:

Il DSL. Il consiglio che Structurizr dà ai suoi utenti attuali è di convertire al DSL. Dalla loro pagina di aiuto sull'editor di workspace: "A DSL representation of your workspace (excluding documentation) can be found on the DSL tab" — una rappresentazione DSL del tuo workspace (documentazione esclusa) si trova nel tab DSL. L'editor di workspace in sé è stato dismesso a febbraio 2022 ma resta raggiungibile a un URL della forma https://structurizr.com/workspace/XXXXX/workspace-editor, dove XXXXX è l'ID del tuo workspace. Aprilo, clicca sul tab DSL, copia tutto, salvalo come workspace.dsl.

Nota la parentesi nella loro frase. La rappresentazione DSL esclude la documentazione. Se hai scritto documentazione o ADR dentro il workspace invece di puntare !docs e !adrs a file Markdown in un repository, il tab DSL non te li restituirà.
Il JSON. Le indicazioni di migrazione di Structurizr ti mandano al link "export your workspaces" in cima alla pagina. Produce workspace.json. Prendilo anche se hai già il DSL. È il formato che accettano sia il playground di Structurizr sia local, e local cerca workspace.dsl e workspace.json in quest'ordine.
Tutto quello che i due file si perdono. Documentazione scritta dentro il workspace, immagini che hai caricato, decisioni con la loro cronologia di stato. Apri il workspace nella UI e copia in Markdown quello a cui tieni finché la UI esiste ancora.
Fai commit di entrambi i file in un repository. Non in una cartella sul portatile. In un repository, accanto al codice che descrivono, dove la prossima persona li troverà.

Ripeti per ogni workspace. Se ne hai dodici, falli tutti in una volta invece di prometterti che ci tornerai.

Una cosa che non sono riuscito a stabilire: Structurizr non ha pubblicato, in nessun posto che io abbia trovato, se i dati dei workspace verranno cancellati il 30 settembre o soltanto resi irraggiungibili. Non dare per scontato di poterli richiedere indietro a ottobre. E non dare per scontato nemmeno il contrario. Prendi i file.

Dove metterlo

Quattro opzioni oneste. Vanno bene per team diversi, e tre di esse non sono archyl.

Opzione 1: il tooling di Structurizr stesso

È la risposta giusta per più team di quanti qualsiasi blog di un vendor ti dirà, e dovrebbe essere la prima cosa che quantifichi.

Structurizr non sta sparendo. Il servizio cloud sì. La loro pagina EOL mappa i vecchi prodotti su quelli nuovi: Lite è sostituito da local, la CLI da pull / push / export, e l'installazione on-premises da server. Se oggi sei su Lite o sulla CLI, anche tu hai una migrazione davanti, solo molto più piccola.

local è descritto nella loro documentazione così: "the free and open source local command provides a way to view diagrams and modify their layout" — il comando local, gratuito e open source, permette di visualizzare i diagrammi e modificarne il layout. Gira sulla tua macchina, in ascolto su localhost. Il loro quickstart sono due comandi: docker pull structurizr/structurizr, poi docker run -it --rm -p 8080:8080 -v PATH:/usr/local/structurizr structurizr/structurizr local. Puntalo a una directory che contiene il tuo workspace.dsl, apri http://localhost:8080, modifica il file, ricarica il browser.
Il playground è il loro suggerimento per un uso occasionale: carichi workspace.dsl o workspace.json, guardi i diagrammi, chiudi il tab.
server è quello che sostituisce ciò che il servizio cloud faceva per te: pubblicare i workspace a un pubblico più ampio. Ha un nucleo open che è gratuito se lo compili dai sorgenti, con storage su filesystem, ricerca Lucene e nessuna autenticazione. I binari precompilati aggiungono SAML, controllo degli accessi basato sui ruoli, token di condivisione privati, storage S3 e Azure Blob, Elasticsearch e una API di amministrazione, e richiedono una licenza: 300 £ al mese da 1 a 20 utenti unici, 600 £ da 21 a 50, 900 £ da 51 a 100, con fatturazione annuale. La loro definizione di utente unico conta chiunque visualizzi un diagramma, anche attraverso un iframe o un'immagine incorporata, non solo chi edita.

A chi va bene: ai team il cui modello è già DSL in Git, i cui lettori sono ingegneri, e il cui uso principale del servizio cloud era il rendering. Tieni il tuo DSL esattamente com'è, tieni le viste di deployment e quelle dinamiche che il nostro importer scarta, e il tooling è scritto dalla persona che ha inventato il modello C4. Se questo sei tu, smetti di leggere qui e vai a lanciare il comando Docker.

A chi non va bene: ai team che hanno bisogno che cento non-ingegneri sfoglino i diagrammi senza che tu debba far girare un server, e ai team per cui 300 £ al mese per venti lettori si legge peggio di un prezzo SaaS per editor. E ancora una, che è l'argomento su cui poggia tutto il resto di questo articolo: il self-hosting preserva il tuo modello, non lo mantiene. Il workspace che si è impolverato nel cloud si impolvererà anche in local. Nessuno rilancia il DSL quando cambia il codice.

Opzione 2: tenere il DSL nel repo e smettere di pagare uno strumento

L'opzione più sottovalutata, e la più economica.

workspace.dsl in Git, revisionato in pull request come qualunque altra cosa, renderizzato all'occorrenza quando qualcuno ha davvero bisogno di un'immagine. local lo renderizza in un container. Lo fa anche il playground. Se preferisci abbandonare del tutto la sintassi di Structurizr, LikeC4 ha licenza MIT, si scrive come file .c4 nel tuo repository e si pubblica tramite un plugin Vite, componenti React o web component, così i diagrammi si possono incorporare in un sito di documentazione che già gestisci.

A chi va bene: ai team in cui il pubblico dei diagrammi è una manciata di ingegneri capaci di leggere un DSL, e in cui la risposta onesta a «ogni quanto qualcuno apre questa roba?» è «all'onboarding e durante gli incidenti». Non perdi niente di ciò che stavi usando e il tuo costo ricorrente è zero.

A chi non va bene: a chiunque abbia diagrammi letti da persone che non cloneranno un repository. Il che, se stavi pagando il servizio cloud, potrebbe essere esattamente il motivo per cui pagavi.

Opzione 3: un altro strumento C4 hosted

Se il servizio cloud stava facendo un lavoro per te, sostituirlo con un altro strumento hosted è una mossa ragionevole, e dovresti guardarne più di uno.

IcePanel è il sostituto più simile: uno strumento C4 visuale prima di tutto, con servizio hosted e un piano gratuito da cinque editor, viewer illimitati e fino a 100 oggetti di modello, con piani a pagamento a partire da 40 $ per editor al mese con fatturazione annuale. Il loro confronto con Structurizr dice "model objects can be imported from Structurizr, Backstage, and a REST API" — gli oggetti di modello possono essere importati da Structurizr, Backstage e una REST API. Non sono riuscito a trovare il formato di file accettato documentato sulle pagine a cui ho potuto accedere, quindi prima di impegnarti carica esattamente il file che hai estratto nella sezione qui sopra e verifica cosa sopravvive. Questo consiglio vale per ogni strumento citato in questo articolo, incluso il nostro.

A chi va bene: ai team che vogliono un editor drag-and-drop e viewer che non sono ingegneri.

A chi non va bene: ai team che si sono spostati su Structurizr proprio perché il modello era testo. Rinunciare all'architettura-as-code per sfuggire alla chiusura di un cloud è uno scambio strano, e lo sentirai la prima volta che vorrai fare il diff di una modifica.

Opzione 4: archyl

Abbiamo costruito un importer di Structurizr DSL, quindi questa è l'opzione che conosco meglio e quella che dovresti leggere con più scetticismo.

Porta workspace.dsl, non workspace.json. Archyl fa il parsing del testo Structurizr DSL. Non esiste un percorso per il JSON del workspace. Se il link di export ti ha dato solo JSON, leggi la sezione più sotto prima di provarci.

Apri un progetto, scegli Structurizr DSL nella modale di import, carica il file .dsl o incollalo. Cosa passa: person e softwareSystem al livello superiore, container e component annidati, nomi e descrizioni, le stringhe di tecnologia su container e component e sulle relazioni, i tag separati da virgola, i blocchi group a qualsiasi profondità appiattiti in tag group:<name>, e le relazioni dichiarate ovunque nel file, anche dentro il corpo degli elementi. I tipi di container e di relazione sono dedotti dalle tue stringhe di tecnologia e dalle tue etichette. I sistemi esterni vengono riconosciuti dal tag External System o External. L'importer è testato contro il workspace di esempio Big Bank dello stesso Simon Brown.

Cosa non passa, che conta di più:

Tutto il layout e lo stile. I blocchi views, configuration e styles vengono saltati. Archyl calcola invece un layout automatico. Il layout manuale è una delle cose che Structurizr vende, quindi questa è proprio la cosa in cui il tuo vecchio strumento era il migliore, e ci stai rinunciando.
!docs e !adrs. Le direttive vengono saltate. Archyl ha ADR e documentazione; l'importer di Structurizr non li riempie.
!include. I workspace su più file vanno appiattiti prima dell'import, altrimenti il contenuto incluso semplicemente non c'è.
Ambienti di deployment, deployment node e infrastructure node. Non importati.

L'importer ti restituisce quasi tutto questo come lista di avvisi nella schermata di risultato dell'import, nei termini stessi del file sorgente:

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

Due precisazioni al riguardo, perché una lista di cui ti puoi fidare vale più di una lista che ci fa fare bella figura. Primo, gli ambienti e i node di deployment vengono saltati: archyl modella la struttura statica, non la topologia di deployment. Il parser li nomina con il numero di riga nella lista di avvisi, quindi un blocco deploymentEnvironment "Live" arriva come una riga che puoi leggere invece che come una scoperta successiva. Secondo, un avviso ti dice cosa il parser ha rifiutato; non ti dice che per il resto l'import è stato perfetto. Rileggiti il modello dopo.

L'unico argomento per pagare questo invece di far girare local: archyl ricontrolla il modello rispetto al repository e assegna un punteggio allo scarto, così un modello che smette di corrispondere al codice lo dice, invece di diventare silenziosamente sbagliato. È il drift score, è deterministico, e gira senza nessuna chiamata all'AI. Se il tuo workspace Structurizr era accurato e aggiornato il giorno in cui il cloud è passato in sola lettura, questo non ti serve e non proverei a vendertelo. Se era fermo da diciotto mesi, lo strumento non è mai stato il problema, e spostarlo altrove non lo sistemerà.

Due cose da tenerci sul groppone. Il piano Developer gratuito limita un progetto a 100 oggetti di modello, quindi un workspace con cinquanta sistemi e i loro container non ci sta dentro; e archyl è cloud-first, con self-hosting solo sul tier Custom. La ragione che Structurizr ha dato per chiudere il servizio cloud, nello stesso annuncio che riporta le date, è che i team di ingegneria sono stati riluttanti a pubblicare i diagrammi di architettura nel cloud e che l'utilizzo era calato costantemente. Se questo descrive il tuo team di sicurezza, l'opzione 1 ti calza meglio di noi, e non dovresti passare due settimane a scoprirlo dentro un processo d'acquisto.

Se tutto ciò che hai è un file JSON

Il link di export sulla tua dashboard ti dà workspace.json, ed è il file che la maggior parte delle persone si ritroverà in mano. Dove atterra:

Structurizr local e il playground lo leggono direttamente. Niente da convertire.
Archyl no. Prendi invece il DSL dal tab DSL, e fallo prima del 30 settembre. Se il workspace è stato scritto attraverso la Workspace API e il tab DSL non ti dà qualcosa di utilizzabile, due ripieghi: collega il repository e lascia che la discovery con AI proponga il modello a partire dal codice, oppure punta un coding agent sul JSON e faglielo scrivere attraverso il server MCP, che è la ricetta descritta qui.
Da qualunque altra parte: chiedi prima di migrare, non dopo.

Scegliere, in un paragrafo

Se il tuo modello è già DSL in Git e i tuoi lettori sono ingegneri, fai girare local e spendi altrove i soldi risparmiati. Se ti serve un'istanza condivisibile e con controllo degli accessi e puoi sostenere la licenza, server è la cosa più vicina a quello che il servizio cloud faceva per te. Se vuoi un editor visuale e viewer non tecnici, guarda IcePanel. Se il workspace che hai appena esportato era già superato, ed è superato perché aggiornarlo a mano era la quarta priorità di qualcuno, allora non è lo strumento che va sostituito, ed è esattamente questa la tesi di archyl.

Qualunque di queste tu scelga: tira fuori i file prima. Il tab sparisce insieme al servizio.

Altro sulla meccanica: importare progetti Structurizr, LikeC4 e IcePanel, la pagina di migrazione da Structurizr e un confronto 2026 degli strumenti C4. Se il modello in sé è nuovo per te, parti da il modello C4 e l'architecture drift.