Проект с 48 цветами в одной палитре и правками раз в квартал закрывается JSON-файлом в репозитории: настройка занимает около 15 минут, отдельного сопровождения не требует. Палитра платформы, которую ежедневно правят 10 дизайнеров, а читают 20 разработчиков, упирается в конфликты слияния в Git уже на первой неделе, и тогда таблица в PostgreSQL или сервис дизайн-токенов обходится дешевле ручного сведения версий.
На выбор влияют масштаб, частота изменений, требования к версионированию и аудиту, интеграции и ресурсы на поддержку. Ниже разобраны границы применимости JSON-файла палитры, файла в репозитории, базы данных, специализированных сервисов и встроенных средств дизайн-систем, приведены сравнительная таблица, чек-лист и риски миграции.
Критерии выбора системы хранения цветовых палитр
Пять параметров снимают большинство спорных решений до начала работ. Оценка проекта по ним занимает 10-15 минут и опирается на факты, а не на вкусовые предпочтения команды.
Пример разбора: палитра корпоративного лендинга (48 цветов, один редактор, правки раз в квартал) живёт в JSON-файле. Палитра SaaS-платформы (около 600 токенов, 10 дизайнеров, ежедневные правки, три продукта) требует сервиса дизайн-токенов или таблиц в БД, потому что каждый второй пул-реквест с файлом даёт конфликт слияния.
Масштаб проекта и количество цветов
До 100 цветов и 1-2 палитры держат в одном файле: такой объём читается за минуту, и diff в пул-реквесте остаётся обозримым. Диапазон 100-1000 цветов с несколькими брендами или темами (светлая, тёмная, высококонтрастная) удобнее вести в сервисе дизайн-токенов, который сам собирает CSS, SCSS и JSON. Больше 1000 цветов, связи между цветом, компонентом и темой, несколько продуктов на общей палитре требуют таблиц: файл на 3000 строк никто не проверяет вручную.
Считают не только количество оттенков. Девять команд, использующих одну палитру, создают нагрузку выше, чем один проект с 400 оттенками: важны число потребителей и число мест, куда нужно доставить обновление.
Частота изменений и требования к версионированию
Правки раз в неделю или реже силами одного редактора закрывает Git: коммит, тег версии, откат через revert. Git хранит историю, но конфликты не предотвращает: двое, правившие один файл, получат merge conflict вместо автоматического слияния.
Ежедневные правки от нескольких человек требуют блокировок, черновиков и журнала, где видно, кто и когда изменил цвет. Требование аудита (кто изменил, когда, что было до правки) сразу переводит задачу в сервис или БД: в Git авторство есть, но нет ролей и согласования.
Необходимость интеграций и автоматизации
Файл в репозитории подхватывается CI/CD без дополнительных компонентов: шаг сборки читает colors.json и раздаёт токены. Обратной синхронизации нет, каждое изменение в Figma переносят руками.
Сервис с API отдаёт одну палитру в нескольких форматах одновременно: JSON для сборки, SCSS-переменные для стилей, XML для Android. Пример: сервис дизайн-токенов по вебхуку из Figma пересобирает пакет и открывает пул-реквест в репозиторий за 2-3 минуты.
Проверку контраста и генерацию читаемых имён (primary-600 вместо blue-42) можно отдать внешним моделям. Агрегатор API вроде AiTunnel даёт единый интерфейс к более чем 200 моделям, включая GPT, Gemini и Claude, с оплатой в рублях, что удобно для массовой проверки палитры на требования WCAG 2.2: 4.5:1 для обычного текста и 3:1 для крупного.
Обзор подходов и форматов хранения палитр
Пять вариантов покрывают большинство задач. Разница между ними в том, где лежат данные, как они версионируются и какие форматы отдаются наружу.
- JSON-файл палитры - один файл, например colors.json, с группами цветов и значениями в HEX, RGB или HSL. Данные лежат в файловой системе, версионируются в Git, редактируются вручную.
- Файл палитры в репозитории - цвета описаны в исходном формате проекта: SCSS или LESS-переменные, CSS custom properties, .ase для Adobe, .gpl для GIMP. Файл попадает в пакет или выносится в отдельный репозиторий токенов.
- База данных - реляционная (PostgreSQL, MySQL) или документная (MongoDB). Годится для больших объёмов, конкурентного доступа, аудита и выборок по связям. Отдаёт данные через API.
- Специализированные сервисы - управление дизайн-токенами (Style Dictionary, Theo, Tokens Studio, Chromatic). Хранят токены централизованно, собирают CSS, SCSS, JSON, iOS, Android, связываются с CI/CD.
- Встроенные решения дизайн-систем - токены живут рядом с компонентами и документацией, например в Storybook или во внутренней дизайн-системе. Палитра обновляется тем же релизом, что и компоненты.
Форматы делят на три группы: обменные (JSON, Design Tokens), платформенные (SCSS, LESS, CSS) и графические (.ase, .gpl, .sketchpalette). Платформенные и графические форматы почти всегда выводят из обменного: держать единственный источник правды проще, чем поддерживать пять наборов цветов.
Когда достаточно JSON-файла или файла в репозитории
Сценарий: один или два проекта, до 100 цветов, один-два редактора, правки раз в неделю или реже, интеграция ограничена сборкой. Файл в репозитории закрывает такую задачу полностью, а стоимость поддержки близка к нулю.
Ограничения фиксируют заранее: ручное редактирование, конфликты при параллельной работе, отсутствие проверки значений и аудита. Валидация в CI и одинаковый стиль именования снимают часть рисков.
Пример структуры JSON-файла палитры
Файл хранит группы цветов, значения в HEX и RGB, а также метаданные: версию, дату, автора. Структура читается и человеком, и сборкой.
{
"meta": {
"version": "2.3.0",
"updated": "2026-09-14",
"author": "design-system"
},
"primary": {
"main": { "hex": "#0055FF", "rgb": "0, 85, 255" },
"dark": { "hex": "#0033AA", "rgb": "0, 51, 170" }
},
"secondary": {
"main": { "hex": "#FF7A00", "rgb": "255, 122, 0" }
},
"neutral": {
"text": { "hex": "#1A1A1A", "rgb": "26, 26, 26" },
"bg": { "hex": "#FFFFFF", "rgb": "255, 255, 255" }
}
}
Метаданные с версией упрощают разбор инцидента: по номеру в файле видно, какая сборка фронтенда собрана на устаревшей палитре.
Организация файла палитры в репозитории
Рабочая схема: каталог /design-tokens/ в корне проекта, файл colors.json и сгенерированные из него артефакты, например _colors.scss и variables.css. Сгенерированные файлы помечают в .gitignore, если они собираются на шаге CI, либо коммитят, если сборка не автоматизирована.
- Валидация JSON и проверка обязательных ключей (hex, rgb) на шаге CI: падение сборки на битом файле дешевле, чем белый текст на белом фоне в продакшне.
- Проверка формата значений регулярным выражением: #RRGGBB и три канала RGB в диапазоне 0-255.
- Git-хук pre-commit для запуска проверки локально, до пуша.
- Тег версии при выпуске палитры в прод: v2.3.0, откат через git revert.
Если палитр несколько (бренды, темы), их держат отдельными файлами с общим базовым набором: colors.base.json, colors.brand-a.json, colors.theme-dark.json. Общий набор исключает дублирование и расхождение значений.
Когда оправдана база данных или специализированный сервис
Признаки перехода: больше 1000 цветов, ежедневные параллельные правки, требование аудита с ролями, сложные связи между цветами, темами и компонентами, потребность в API для синхронизации с кодом и дизайн-инструментами. Каждый признак по отдельности решается сервисом, все вместе чаще упираются в БД с собственным API.
База данных для хранения палитр: плюсы и минусы
Плюсы: масштабирование до десятков тысяч записей, конкурентный доступ, транзакции, разграничение прав, аудит и выборки по связям. Минусы: настройка и сопровождение, резервное копирование, необходимость API-слоя, избыточность для палитры из 40 цветов.
Схема на PostgreSQL из трёх таблиц покрывает основную логику:
CREATE TABLE palettes ( id bigserial PRIMARY KEY, name text NOT NULL, brand text, created_at timestamptz DEFAULT now() ); CREATE TABLE colors ( id bigserial PRIMARY KEY, palette_id bigint REFERENCES palettes(id), name text NOT NULL, hex char(7) NOT NULL, rgb text NOT NULL, purpose text, updated_at timestamptz DEFAULT now(), UNIQUE (palette_id, name) ); CREATE TABLE color_versions ( id bigserial PRIMARY KEY, color_id bigint REFERENCES colors(id), hex char(7) NOT NULL, changed_by text NOT NULL, changed_at timestamptz DEFAULT now() );
Таблица color_versions даёт аудит: кто, когда и на какое значение изменил цвет. Ограничение UNIQUE (palette_id, name) не даёт завести два primary.main в одной палитре. PostgreSQL, API-слой и бэкапы удобно держать на облачных ресурсах, например на Timeweb Cloud, где СУБД, серверы и хранилище заказываются отдельными сервисами.
Выбор СУБД и схему хранения с учётом нагрузки и бэкапов разбирает отдельный материал про базы данных для хранения сведений. Для палитр часто хватает одной инстанции без реплик: объём данных измеряется мегабайтами, а нагрузка на чтение кратна числу сборок.
Специализированные сервисы и дизайн-системы
Сервисы управления дизайн-токенами решают три задачи: централизованное хранение, автоматическая сборка в нужные форматы и связь с CI/CD. Style Dictionary по одному JSON собирает CSS, SCSS, LESS, iOS, Android и документацию. Tokens Studio связывает палитру с Figma, Chromatic показывает изменения визуально в пул-реквестах.
Встроенные решения дизайн-систем хранят токены рядом с компонентами: Storybook с аддоном токенов показывает палитру и её применение в интерфейсе. Плюс в том, что цвет и компонент меняются одним релизом. Риски: привязка к вендору, стоимость на пользователя, ручной перенос данных при смене сервиса. Экспорт проверяют заранее: если сервис не отдаёт палитру в JSON, выход из него будет трудоёмким.
Сравнительная таблица подходов
| Критерий | JSON-файл | Файл в репозитории | База данных | Сервис токенов | Дизайн-система |
|---|---|---|---|---|---|
| Масштаб | до 100 цветов | до 300 цветов, 1-3 палитры | тысячи записей | 100-1000+ токенов | зависит от системы |
| Частота изменений | редко, один редактор | редко и средне | ежедневно, много редакторов | ежедневно | по релизам компонентов |
| Версионирование | Git, коммиты и теги | Git, коммиты и теги | таблица версий, снимки | встроенная история | версии пакета |
| Аудит (кто и когда) | git blame | git blame | полный, с ролями | журнал сервиса | по истории релизов |
| Интеграции | чтение в CI | сборка пакета | через API | API, вебхуки, Figma | внутри стека |
| Сложность поддержки | низкая | низкая | высокая | средняя | средняя |
| Стоимость | 0 | 0 | сервер и время администратора | подписка на пользователя | стоимость стека |
Оценки даны по трём состояниям: низкая, средняя, высокая. Для смешанных схем, например JSON в репозитории плюс сборка через Style Dictionary, строки комбинируют: хранение берут из первой колонки, интеграции из четвёртой.
Чек-лист для принятия решения
Семь вопросов, ответы на которые указывают на конкретный подход.
- Сколько цветов и палитр? Меньше 100 и 1-2 палитры - файл; 100-1000 или несколько брендов - сервис токенов; больше 1000 - БД.
- Как часто меняется палитра? Реже раза в неделю - файл; ежедневно - сервис или БД.
- Сколько человек редактируют одновременно? Один-два - файл; больше - система с блокировками.
- Нужна история изменений с автором и ролями? Достаточно авторства правки - хватит Git; нужны роли и согласование - БД или сервис.
- Нужна автоматическая синхронизация с Figma и кодом? Да - API и вебхуки; нет - сборка из репозитория.
- Есть ресурсы на поддержку? Учтите сервер, бэкапы, обновления и дежурного администратора. Ресурсов нет - выбирайте файл или сервис с оплатой поддержки.
- Какие требования к безопасности и доступу? Публичный репозиторий не подходит для палитры внутренних продуктов с ограниченным доступом; тогда нужен сервис с ролями или БД.
Быстрое правило: ответы «мало, редко, один, нет, нет, нет, публично» означают JSON-файл. Ответы «много, часто, много, да, да, да, ограниченный доступ» указывают на БД или сервис.
Типичные подводные камни при миграции между подходами
Переход между системами хранения ломает рабочие процессы чаще, чем сама новая система. Пять рисков встречаются регулярно.
- Потеря данных при переносе. Скрипт импорта пропускает часть записей, если схема новой системы строже старой. Резервная копия исходного файла и сверка количества цветов до и после обязательны.
- Несовместимость форматов. .ase или .gpl не переносятся в JSON напрямую: часть градиентов и групп теряется. Промежуточный формат JSON сглаживает переход.
- Дублирование цветов. После импорта в БД появляются primary-blue и blue-primary с одинаковым HEX. Ограничение UNIQUE и предварительная нормализация имён решают проблему.
- Ссылки в коде. Старые имена переменных перестают существовать, сборка падает в десятках файлов. Переименование делают через алиасы с периодом сосуществования двух схем.
- Простой команды. Переключение в пятницу вечером без плана отката означает выходные в аварийном режиме. Тестовый прогон на копии проекта, окно миграции и план возврата к старой схеме снижают риск.
Порядок проверки: экспорт всех цветов, импорт в тестовую среду, сборка проекта на новой палитре, визуальное сравнение двух сборок, затем переключение продакшна. Логику оценки рисков и совместимости подробно разбирает материал про миграцию или развёртывание с нуля, включая шаблон меморандума для руководства.
Практические сценарии использования
Небольшой стартап, одно веб-приложение. 40-60 цветов, один дизайнер, один фронтенд-разработчик, правки раз в месяц. Выбор: colors.json в каталоге /design-tokens/ плюс генерация SCSS на шаге сборки. Версионирование через Git, откат через revert. Альтернатива при росте до трёх продуктов - сервис дизайн-токенов с бесплатным тарифом.
Средняя компания, дизайн-система и несколько продуктов. 300-600 токенов, три темы, 10 дизайнеров, 20 разработчиков, ежедневные правки. Выбор: сервис управления токенами с API, вебхуком из Figma и автоматической генерацией CSS, SCSS, JSON, iOS и Android. Роли и история изменений встроены, отдельный сервер не нужен. Альтернатива - Style Dictionary в CI плюс собственный репозиторий токенов.
Крупная организация, микросервисы и много команд. Больше 1000 цветов, общая палитра на 15 команд, требование аудита и ролевого доступа. Выбор: PostgreSQL с таблицами palettes, colors, color_versions и внутренним API. Каждая команда читает палитру по API, изменения проходят согласование. Здесь пригодятся подходы из материала про архитектуру масштабирования: кеш перед API снижает нагрузку от частых сборок, реплики разгружают чтение.
Общее правило для всех трёх сценариев: один источник правды и автоматическая выгрузка во все потребительские форматы. Ручной перенос цветов между Figma, кодом и документацией даёт расхождения, которые всплывают на этапе приёмки дизайна.