Сценарий, знакомый многим в крупных компаниях: команда нашла удобный облачный редактор, начала в нём работать, а потом служба безопасности узнала, что файлы хранятся на зарубежных серверах, — и всё, инструмент под запретом. Дизайнеры расстроены, безопасники непреклонны, и обе стороны по-своему правы. Ровно этот конфликт решает self-hosted — разворачивание редактора в собственном контуре. Слово звучит как что-то сугубо для системных администраторов, но за ним стоит простой и понятный дизайнеру выбор: где физически живут ваши файлы — в чужом облаке или у вас дома.
Разберём честно, без маркетинга: что это такое, когда действительно критично, чего стоит, и — важно — кому self-hosted на самом деле не нужен. Потому что навязывать его всем подряд так же нечестно, как делать вид, что облако подходит каждому.
Облако и свой контур — в чём разница
Облачный редактор вроде Figma хранит файлы на серверах вендора. Это невероятно удобно: вы ничего не настраиваете, открыли браузер — и всё работает, обновления прилетают сами, бэкапы делает кто-то за вас. Плата за удобство — ваши данные лежат там, где вы их не контролируете, по правилам и в юрисдикции чужой компании.
Self-hosted переворачивает эту сделку. Вы разворачиваете редактор на своих серверах, и файлы физически остаются в вашем периметре — под вашим управлением доступом, вашими бэкапами, вашим аудитом. Взамен на вас ложится обслуживание. Это не «лучше» и не «хуже» — это другой набор компромиссов, и выбирать надо по тому, что для вас важнее: беззаботность или контроль.
Когда контроль действительно критичен
Есть ситуации, где вопрос решается не удобством, а требованием. Первая и самая частая — 152-ФЗ и персональные данные: если в макетах и прототипах фигурируют реальные данные пользователей, многим организациям попросту нельзя хранить их за рубежом, и точка. Вторая — банки и госсектор, где требования к изолированному контуру и аудиту часто исключают любые внешние облака в принципе. Третья — корпоративная тайна: дизайн ещё не вышедшего продукта — чувствительная информация, и держать её в чужой инфраструктуре — риск, который не всякая компания готова принять.
Есть и четвёртая, более приземлённая причина — стабильность доступа. Инструмент внутри своего контура не зависит ни от блокировок, ни от санкционных ограничений, ни от того, решит ли зарубежный вендор однажды уйти с рынка. Для команды, которой важно, чтобы рабочий редактор просто был доступен завтра и через год, это весомый аргумент сам по себе.
Плюсы и минусы без прикрас
Честный баланс выглядит так. В плюсах — полный контроль над данными, соответствие требованиям регулятора, независимость от внешних облаков и предсказуемость: инструмент ведёт себя так, как вы его настроили, и не меняется без вашего ведома. В минусах — обслуживание: кто-то должен развернуть систему, обновлять её и делать бэкапы. Для организации с ИТ-отделом это рутина, для команды из трёх дизайнеров без единого админа — реальная дополнительная нагрузка. Облако в этом смысле честно проще: там «всё уже работает», и это его законное преимущество.
Как это устроено у Rugma
Rugma спроектирована под такой сценарий с самого начала. Это набор небольших сервисов, которые разворачиваются в вашем контуре через Docker; хранение и раздача идут с ваших серверов, без обязательных зарубежных зависимостей. Установка сведена к нескольким командам, а работать система может полностью офлайн — вплоть до сети без доступа в интернет, что как раз и нужно самым закрытым контурам. Данные проекта не покидают ваш периметр — ни при редактировании, ни при экспорте.
Практический смысл офлайн-работы недооценивают. В изолированной сети не важно, что происходит с внешним миром: инструмент не «отвалится», потому что где-то сменились правила, и не потянет данные наружу, потому что наружу физически нет канала. Для банка или госоргана это не приятная опция, а условие, при котором редактором вообще можно пользоваться. И что немаловажно — офлайн-режим снимает вечную головную боль «а вдруг завтра сервис заблокируют или уйдёт с рынка»: то, что стоит в вашем контуре и не тянет ничего снаружи, никуда не денется по чужой воле.
Попробуйте прикинуть прямо сейчас. Задайте себе три вопроса. Фигурируют ли в ваших макетах реальные персональные данные? Есть ли у вашей организации формальные требования к хранению данных в России? Есть ли кому обслуживать сервер? Если на первые два «да» и на третий тоже «да» — self-hosted почти наверняка ваш выбор. Если на первые два «нет» — скорее всего, вам спокойнее в облаке, и это нормально.
Кому self-hosted не нужен
Скажем прямо: если вы фрилансер или небольшая команда, у вас нет требований по 152-ФЗ и в макетах не лежат чувствительные данные — облачный режим вам, скорее всего, удобнее, и гнаться за self-hosted ради моды не стоит. Он имеет смысл только там, где есть реальное требование держать данные у себя. Зато там, где такое требование есть, альтернатив по сути нет — и тогда развёртывание в собственном контуре из «хотелки безопасников» превращается в единственный рабочий способ вообще пользоваться современным редактором. А если вы как раз переезжаете с облачного инструмента, загляните в разбор переезда с Figma — там про то, что переносится гладко, а что придётся пересобрать.
Итог простой: self-hosted — это про контроль и соответствие закону, а не про «круче облака». Выбирайте по своим требованиям, а не по моде.