Structurizr Cloud закрылся 30 сентября. Что осталось и куда переносить C4-модели

30 сентября 2026 года облачный сервис Structurizr прекратил работу. Для команд, которые хранили там C4-модели, это не просто закрытие ещё одного SaaS: вместе с хостингом исчез привычный способ публиковать архитектуру, раздавать доступ коллегам и встраивать диаграммы в другие системы.

При этом сам Structurizr не умер. DSL, локальные инструменты и новый self-hosted server продолжают развиваться. Разберёмся, что именно закрылось, почему это произошло и какие варианты теперь есть у команд.

Что именно закрылось

Structurizr Cloud появился в 2015 году как сервис для рендеринга и публикации диаграмм, построенных на модели C4. В ноябре 2025 года автор Structurizr Саймон Браун объявил график завершения работы:

31 декабря 2025 года прекратилась регистрация новых аккаунтов;
1 апреля 2026 года workspace бесплатных аккаунтов перешли в read-only;
1 июля все workspace стали read-only, а ежемесячные подписки остановились;
30 сентября 2026 года облачный сервис был выключен.

Это именно EOL облачного сервиса. В актуальной документации он помечен как Structurizr cloud service — no replacement.

Почему закрыли облако? По объяснению автора, инженерные команды неохотно размещали схемы своей программной архитектуры во внешнем облаке. Параллельно появились self-hosted Structurizr on-premises и Structurizr Lite, которые в 2023 году открыли исходный код. Использование cloud-версии постепенно снижалось, поэтому разработка сфокусировалась на локальных и самостоятельно размещаемых инструментах.

В этом есть определённая ирония. Архитектурная документация особенно полезна, когда доступна всей организации, но именно её чувствительность мешает многим организациям доверить такую информацию внешнему SaaS.

Что не закрылось

Закрытие Structurizr Cloud не означает конец Structurizr DSL или подхода models as code.

Вместо нескольких отдельных продуктов появился консолидированный Structurizr vNext. В нём прежние сценарии разделены на команды:

local — локальный просмотр модели и редактирование layout;
server — публикация workspace для команды на собственной инфраструктуре;
export — экспорт в PlantUML, C4-PlantUML, Mermaid, PNG, SVG или статический сайт;
push и pull — работа с workspace API;
validate и inspect — проверка модели;
playground — эпизодический просмотр DSL или JSON в браузере.

Готовые бинарники распространяются как Docker image и Java WAR. Все команды, кроме server, можно использовать бесплатно. Здесь есть важная оговорка: open-core версию server тоже можно запустить бесплатно, если собрать её из исходников. Платная лицензия нужна для server из готовых бинарников и добавляет enterprise-возможности: authentication, role-based access, SAML, внешние хранилища, Elasticsearch, Redis и Admin API. На момент публикации лицензия начинается с 300$ в месяц для установки с 1–20 уникальными пользователями и оплачивается за год.

То есть официальный маршрут после закрытия облака выглядит так:

workspace.dsl / workspace.json              |              +--> Structurizr local              +--> Structurizr server              +--> static site / PlantUML / Mermaid / PNG / SVG              +--> другой совместимый инструмент

Четыре варианта миграции

1. Остаться на Structurizr и работать локально

Если модель поддерживает один архитектор или небольшая команда, Structurizr local — самый прямой вариант. DSL остаётся в Git, диаграммы строятся из той же модели, инфраструктуру поднимать не нужно.

Подходит, когда:

основной workflow уже построен вокруг pull request;
модель редактируют технические специалисты;
совместная работа происходит через Git;
не нужен постоянно доступный портал архитектуры.

Главный компромисс — архитектуру сложнее сделать доступной менеджерам, аналитикам и другим участникам, которые не работают с DSL и Git.

2. Развернуть Structurizr Server

Это официальный путь для организации, которой нужен общий веб-интерфейс. Бесплатный open core предоставляет базовый server с файловым хранилищем и публичными workspace. Лицензируемая сборка добавляет authentication, role-based access, SAML, дополнительные варианты хранения и поиска, распределённые HTTP-сессии и Admin API.

Подходит, когда:

данные должны оставаться внутри корпоративного контура;
команда готова сопровождать ещё один сервис;
важна максимальная совместимость с существующим Structurizr workflow;
стоимость лицензии и эксплуатации приемлема.

Оценивать здесь нужно не только цену лицензии. Появляются обновления, резервное копирование, TLS, SSO, мониторинг, хранение данных и план восстановления.

3. Экспортировать статический портал

Если архитектуру в основном читают, а изменяют редко, можно генерировать статический сайт или изображения в CI и публиковать их во внутреннем портале.

Это простой и устойчивый вариант:

исходная модель остаётся в Git;
публикация автоматизируется;
у читателей нет доступа к редактору;
поверхность атаки минимальна.

Но такой портал плохо подходит для совместного редактирования, обсуждения изменений и работы нескольких команд над единой моделью.

4. Перейти на другой инструмент

Закрытие облака — повод не только перенести файлы, но и пересмотреть сам процесс. За десять лет требования к архитектурной документации изменились: к диаграммам добавились API-контракты, event flows, ADR, связь с задачами и контекст для AI-агентов.

На рынке есть visual-моделлеры, DSL-инструменты и плагины для внутренних developer portals. Но сравнивать их стоит не по красоте диаграмм, а по нескольким рабочим сценариям.

Чек-лист выбора нового решения

Где находится source of truth?

Это файл в Git, база данных сервиса или набор независимых картинок? Можно ли выгрузить модель целиком в структурированном формате?

Одна ли модель лежит под разными представлениями?

Если один и тот же сервис приходится переименовывать на пяти диаграммах, документация снова начнёт расходиться с реальностью.

Кто может вносить изменения?

DSL удобен разработчикам, но может исключить product owner, аналитика или enterprise-архитектора. Визуальный редактор снижает порог входа, но не должен превращать модель в свободный canvas без правил.

Как проходит review?

Недостаточно хранить историю. Для архитектурного изменения полезно видеть намерение, затронутые элементы, ограничения и доказательства реализации.

Связана ли архитектура с контрактами?

Надпись REST на стрелке редко помогает разработчику. Гораздо полезнее знать endpoint, request/response schema, событие или broker channel, через который действительно взаимодействуют системы.

Может ли модель читать инструмент, а не только человек?

AI-агенту бесполезна красивая PNG-схема без устойчивых идентификаторов и семантики. Ему нужна структурированная модель: системы, контейнеры, компоненты, связи, контракты, решения и границы допустимых изменений.

Что произойдёт при закрытии следующего сервиса?

Экспорт должен быть не декоративной кнопкой, а проверяемым путём выхода. Хороший тест: можно ли восстановить рабочее состояние проекта из выгруженного файла без ручного перерисовывания?

Где здесь Viaduct

Небольшой disclosure: я развиваю Viaduct, поэтому смотрю на эту ситуацию не только как пользователь архитектурных инструментов.

Viaduct — визуальная среда для C4-моделей. В одной модели можно связать уровни C1–C4, документацию, sequence flows, ER-схемы и OpenAPI-контракты. Модель доступна AI-инструментам через MCP: агент может не только прочитать архитектурный контекст, но и предложить изменения в самой модели.

Есть два режима:

бесплатная браузерная версия с командными проектами и hosted MCP;
desktop-приложение, в котором проекты хранятся локальными JSON-файлами, а MCP server работает на 127.0.0.1.

Viaduct не стоит воспринимать как drop-in replacement, который автоматически проглотит любой workspace.dsl: прямого импорта Structurizr DSL пока еще нет. Если у вас большая существующая модель и отлаженный DSL workflow, официальный Structurizr local/server будет наиболее консервативным путём.

Но если миграция совпала с необходимостью подключить к архитектуре больше ролей, хранить рядом API-контракты и дать coding agents структурированный контекст, имеет смысл сравнить не только способы рендеринга DSL, но и более широкий workflow.

Главный вывод

Structurizr Cloud закрылся, но C4 и models as code никуда не исчезли. Наоборот, произошедшее хорошо проявило важное свойство архитектурной документации: она должна принадлежать команде не только юридически, но и технически.

У команды должны оставаться:

переносимая структурированная модель;
резервная копия вне выбранного SaaS;
воспроизводимый способ построить представления;
понятный процесс review и обновления;
возможность сменить инструмент без перерисовывания архитектуры с нуля.

Закрытие сервиса — неприятный повод проверить эти свойства сейчас, а не после следующего EOL.

Ссылки

ссылка на оригинал статьи https://habr.com/ru/articles/1098118/