Figma без подписки: что реально работает как замена для команды

MAATRIX

Оплата с российской карты перестала проходить, корпоративный тариф не продлился, а макеты, компоненты дизайн-системы и история правок остались висеть в чужом облаке без доступа. Дизайн-команда в этот момент теряет не абстрактный «модный инструмент», а рабочий процесс: где лежит актуальная версия экрана, кто её правил последним и как передать макет разработчику сегодня, а не через неделю разбирательств с поддержкой. Ниже — трезвый разбор трёх рабочих путей: поднять self-hosted платформу совместного дизайна, перейти на локальные инструменты с ручной синхронизацией файлов или собрать гибридную схему — с честными компромиссами и практикой хранения макетов на своём сервере.

Что вы на самом деле теряете, отказавшись от облачного дизайн-инструмента

Прежде чем выбирать замену, стоит честно назвать вещи своими именами — часть функциональности объективно теряется или работает иначе, и лучше знать об этом заранее, чем упереться в проблему через месяц.

Реально теряется или ухудшается:

• Мгновенное real-time совместное редактирование одного файла. В облачном сервисе несколько человек двигают объекты на одном экране одновременно и видят курсоры друг друга без задержки. На self-hosted платформе это тоже работает, но зависит от вашего сервера и канала — на слабой машине или при плохой связи между удалёнными участниками появляются задержки и рассинхрон, которых не было в облаке с глобальной инфраструктурой вендора. При ручной синхронизации файлов совместного редактирования в реальном времени просто нет — работает модель «один правит, остальные ждут релиза версии».
• Экосистема плагинов и интеграций. У крупных облачных дизайн-инструментов тысячи плагинов: от автоматической расстановки иконок до синхронизации токенов с кодовой базой. У self-hosted альтернатив плагинов на порядок меньше, а многие популярные облачные плагины технически не переносятся — они завязаны на API конкретного вендора.
• Готовые интеграции с таск-трекерами и хендофф для разработчиков. Автоматическая генерация CSS/Swift/Kotlin-кода из слоя, комментарии с упоминанием коллег и уведомлениями в Slack «из коробки» — там, где в облаке это одна кнопка, в self-hosted решении часто нужен отдельный плагин или ручной экспорт спецификаций.
• Библиотеки компонентов от комьюнити и маркетплейс шаблонов. Готовые UI-киты и иконки, которые в облачном сервисе подключаются в пару кликов, на своей платформе либо недоступны, либо требуют ручного импорта файлов.

Что остаётся и часто оказывается даже лучше:

• Полный контроль над данными — макеты физически лежат на вашем сервере, а не в юрисдикции стороннего вендора.
• Отсутствие ежемесячной платы за место в команде — экономика меняется с «за голову» на «за сервер», что на команде от 5-7 человек часто выгоднее.
• Предсказуемость: инструмент не заблокируют, не поднимут цену вдвое и не отключат регион без предупреждения.
• Базовые функции редактирования интерфейсов — векторные слои, компоненты, авто-лейауты, прототипирование — у зрелых self-hosted платформ на месте, разрыв в первую очередь в экосистеме вокруг, а не в самом редакторе.

Дальше — как выбрать конкретный путь под размер команды и срочность ситуации.

Self-hosted платформа совместного дизайна: когда это верный выбор

Если команда привыкла работать в одном файле одновременно и терять совместное редактирование не готова — путь один: поднимать open source платформу дизайна на своём сервере. На конец лета 2026 года зрелый вариант такого класса — Penpot: браузерный редактор с векторными слоями, компонентами, авто-лейаутами и прототипированием, который по интерфейсу близок к привычным облачным инструментам и умеет импортировать файлы в открытом формате .fig.

Технически это не один контейнер, а связка сервисов — фронтенд, backend, модуль экспорта в PDF/PNG/SVG, база данных и Redis для очередей и realtime-уведомлений между открытыми вкладками редактора. Полный пошаговый разбор установки через Docker Compose, включая HTTPS и переменные окружения, — в отдельной статье: как установить и настроить Penpot на VPS. Там же разобран нюанс, который часто ломает совместную работу сразу после переезда: без правильного проксирования WebSocket в nginx realtime-правки коллег просто не долетают друг до друга, хотя сама страница открывается нормально.

Требования к серверу для команды в несколько человек стартуют скромно, но растут при активной параллельной работе с крупными файлами и частым пакетным экспортом — подробный разбор по типичным сценариям от 3 до 50+ участников есть в статье сколько RAM нужно для Penpot. Практический ориентир: небольшой команде хватает пары виртуальных ядер и нескольких гигабайт памяти, но точные цифры сильно зависят от размера файлов и числа одновременных пользователей — измеряйте на своей реальной нагрузке, а не на абстрактном бенчмарке.

Когда self-hosted платформа — правильный выбор:

• Команда от 5 человек и больше, где совместная работа над одним экраном — ежедневная практика, а не редкость.
• Есть кому поддерживать сервер: обновления, бэкапы, мониторинг диска — теперь ваша, а не вендора, ответственность.
• Важна безопасность конкретных данных — макеты финтех-продукта или закрытого корпоративного сервиса не должны утекать в чужой датасет для обучения моделей. Похожая логика разбирается на примере другой профессии: иллюстратор боится, что эскизы уедут в чужой датасет — там принцип «своё хранилище для творческих файлов» тот же самый.

Когда не стоит: команда из 1-2 человек без частой параллельной работы над одним файлом — держать отдельный сервер и обслуживать пять контейнеров ради этого избыточно, дешевле и проще пойти по пути ниже.

Локальные инструменты с ручной синхронизацией файлов: минималистичный путь

Для небольшой команды или фрилансера, у которого нет ресурса администрировать сервер, рабочий вариант — десктопный редактор векторной графики и интерфейсов с ручной синхронизацией файлов через общее хранилище. Реального real-time совместного редактирования тут не будет в принципе — но для многих сценариев (один дизайнер ведёт экран, второй проверяет и комментирует асинхронно) это и не требуется.

Схема простая:

1. Дизайнер работает в локальном приложении, файл лежит на диске в стандартном открытом или полуоткрытом формате.
2. Готовая версия синхронизируется в общее хранилище на вашем сервере — через Nextcloud, Seafile или обычный WebDAV/SFTP.
3. Коллеги забирают актуальную версию, правки возвращаются тем же путём.

Главный риск такой схемы — конфликт версий: два человека одновременно правят один файл, и при синхронизации побеждает тот, кто сохранил последним, а правки второго теряются молча. Смягчается это дисциплиной, а не технологией: договоритесь о правиле «один файл — один активный автор в моменте», используйте блокировку файла на уровне хранилища там, где она есть (Nextcloud умеет блокировать файл при редактировании через приложение), и не полагайтесь на «само разрулится».

Для организации самого хранилища подойдёт классическая связка на VPS — она же служит фундаментом и для гибридной схемы из следующего раздела: как установить и настроить Nextcloud на VPS. Отдельно от Figma-подобного редактора для быстрых схем, диаграмм и совместных досок пригодится лёгкий open source инструмент для рисования — там модель именно "один файл, несколько правок по очереди", что естественно ложится на эту схему.

Плюсы пути: не нужен отдельный сервер под тяжёлый дизайн-стек, ниже порог входа, меньше эксплуатационных забот. Минусы: нет живого совместного редактирования, история версий — это то, что вы сами организуете дисциплиной именования файлов и версионированием на хранилище (разбор ниже), а не встроенная функция редактора.

Гибридная схема: что можно смешивать и как

На практике многие команды в конце августа 2026 года приходят не к одному чистому варианту, а к смеси: self-hosted платформа для активной совместной работы над ключевыми экранами продукта плюс локальные инструменты и общее хранилище для второстепенных задач — экспорта ассетов, черновых набросков, маркетинговых макетов, которые не требуют realtime-соавторства.

Рабочая логика распределения:

Гибрид снижает нагрузку на self-hosted платформу — не всё подряд тащится туда — и даёт живое совместное редактирование там, где оно реально нужно. Обратная сторона: два места хранения требуют дисциплины, иначе через полгода никто не помнит, актуальная версия экрана в Penpot или в чьей-то локальной папке «финал». Заведите одно место — структуру папок в хранилище или страницу во внутренней wiki, — где написано, какой тип файла где живёт и кто отвечает за перенос финальной версии.

Хранение и версионирование макетов на своём сервере: практика

Что бы вы ни выбрали из трёх путей выше, вопрос «где лежит история изменений макета» встаёт в любом случае — в облачном сервисе это было незаметной встроенной функцией, на своём сервере это придётся организовать осознанно.

Три уровня, которые стоит развести физически или хотя бы логически:

Уровень 1 — рабочие файлы редактора. Для self-hosted платформы (Penpot) история версий файла хранится в её собственной базе данных автоматически, пока сама платформа жива и её бэкапят. Для локальных инструментов история — это то, что вы формируете сами: либо через систему контроля версий, либо через дисциплину именования.

Уровень 2 — общее хранилище для синхронизации и обмена. Nextcloud и Seafile из коробки хранят несколько последних версий файла при перезаписи и дают историю изменений через веб-интерфейс — этого обычно достаточно для файлов дизайна, если не нужна полная история на годы вперёд.

Уровень 3 — долгосрочные бэкапы. Отдельная копия и базы self-hosted платформы, и общего хранилища на другом сервере или в другом хранилище — правило «бэкап на том же сервере, что и данные, — не бэкап» здесь работает так же, как для любой другой инфраструктуры.

Практический совет по именованию файлов и структуре папок для команд без версионирования на уровне системы:

/design/
  01-active/          # текущие рабочие файлы
    onboarding-flow.penpot
    checkout-v3.penpot
  02-archive/          # снятые с активной разработки, но нужные для истории
    checkout-v2-2026-06.penpot
  03-export/           # финальные ассеты для разработки
    icons/
    checkout-v3-assets/
  04-client-facing/     # то, что уходит заказчику или в презентации

Дата в имени архивной версии (ГГГГ-ММ) решает проблему «финал», «финал2», «финал_точно» лучше любых интуитивных названий — по дате видно порядок без необходимости открывать файл. Похожая проблема с версионированием разбирается на примере другой профессии — принцип переносится напрямую: версии чертежей на своём сервере вместо папок «финал2».

Для файлов, которые критично не потерять — активная дизайн-система, макеты в разработке — настройте резервное копирование с той же регулярностью, что и для боевой базы данных, а не «когда вспомню». Если self-hosted платформа развёрнута через Docker, дамп базы и архив тома с ассетами делаются одним скриптом по расписанию — это не отличается от бэкапа любого другого self-hosted сервиса на VPS.

Экосистема плагинов: чем реально закрывать дыры

Отсутствие маркетплейса плагинов — самая частая жалоба команд после перехода, и здесь честнее сразу сказать: одним инструментом это не закрыть, придётся собирать замену по частям.

Что стоит сделать в первые недели после перехода:

• Составьте список плагинов, которые реально использовались, а не всех, что были установлены «на всякий случай». Обычно активно используются 3-5 плагинов из десятков установленных — именно на них и стоит тратить время поиска замены.
• Автоматизацию расстановки/переименования слоёв и генерацию иконок ищите среди плагинов конкретно выбранной платформы — экосистема растёт, но проверяйте актуальный список на момент перехода, а не по старым обзорам.
• Синхронизацию токенов дизайн-системы с кодом без готового плагина закрывайте вручную через экспорт переменных в JSON и скрипт конвертации под нужный формат (CSS-переменные, конфиг Tailwind) — дольше, чем кнопка в облачном плагине, но скрипт пишется один раз.
• Хендофф для разработчиков компенсируется явной спецификацией: экспорт слоя в SVG плюс файл с отступами, размерами шрифта и цветами — менее элегантно, чем автогенерация кода, но разработчик получает всё нужное.

Отдельно подготовьте команду морально: часть автоматизаций, экономивших время в облачном инструменте, снова станет ручной работой. Это не повод отказываться от перехода, но заложите в план запас времени на адаптацию.

Частые вопросы