Polysite: одна админка Payload CMS для нескольких независимых сайтов

22 октября 2026 г.•Александр Андреев

Обычно новый проект на Payload начинается с отдельной установки CMS. Нужен ещё один сайт — появляется второй проект, затем третий: со своей админкой, пользователями, обновлениями и инфраструктурой.

Polysite предлагает другой подход: одна установка Payload обслуживает сразу несколько независимых сайтов. У каждого — собственный домен, оформление, страницы и пользователи, а публичная часть работает на Nuxt 4.

Автор проекта — Harsh Doshi, единственный контрибьютор репозитория. Код опубликован 13 октября 2026 года, статус — pre-1.0: релизов ещё нет, последний тег — v0.1.0-beta.4. Звёзд на GitHub на момент публикации тоже нет, так что оценивать зрелость проекта стоит с поправкой на возраст: ему меньше двух недель. Развернуть систему самостоятельно при этом можно уже сейчас.

Payload как центральная CMS

В основе Polysite лежат Payload 3 и PostgreSQL. Payload отвечает за хранение контента, пользователей и прав доступа и предоставляет административный интерфейс — админка работает в привычном для третьей версии окружении Next.js.

Публичная часть сайтов построена на Nuxt 4, а перед ними стоит Caddy: он терминирует TLS и маршрутизирует запросы по доменам.

                 +--------------------------+
                 |       Caddy (TLS)        |
                 +------------+-------------+
              +---------------+---------------+
              |               |               |
        site-a.ru        site-b.ru       site-c.ru
       (Nuxt 4)         (Nuxt 4)        (Nuxt 4)
              |               |               |
              +---------------+---------------+
                              |
                 +------------+-------------+
                 |  Payload CMS 3 (Next.js) |
                 +------------+-------------+
                              |
                       +------+------+
                       |  PostgreSQL |
                       +-------------+

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

Для Payload это хороший практический пример headless-архитектуры: CMS необязательно должна использовать тот же фреймворк, что и публичный сайт. Nuxt получает контент из Payload API, поэтому frontend и CMS можно развивать независимо.

Сайты изолированы друг от друга

Главная задача любой многосайтовой CMS — не просто добавить к документу поле site, а сделать так, чтобы редактор одного сайта не получил доступ к содержимому другого.

В Polysite контент, медиа и пользователи привязаны к конкретному сайту, а доступ определяется членством и ролями: пользователь видит только назначенные ему сайты, и его возможности внутри каждого из них зависят от назначенной роли.

Роли при этом не обязательно жёстко описывать в коде. Суперадминистратор создаёт и меняет их прямо в административной панели — какие коллекции и какие операции разрешены. Подход fail-closed: всё, что не разрешено явно, запрещено.

Администратор — site-a.ru, site-b.ru, site-c.ru
Редактор №1 — site-a.ru
Редактор №2 — site-b.ru, site-c.ru

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

Конструктор страниц, темы и SEO

Polysite рассчитан не только на централизованное хранение данных. В проекте есть визуальный конструктор страниц на основе типизированных блоков: hero-баннеры, текст, FAQ-аккордеоны, сетки возможностей, формы записи и петиции. Страницу можно предпросматривать в мобильной, планшетной и десктопной ширине.

Поддержаны черновики, версии со сравнением и восстановлением, отложенная публикация и автоматическое снятие с публикации, а также метка «черновик готов к ревью».

Отдельный интерес представляет система тем. Публичная часть построена на Nuxt Layers: сайты используют общую базовую реализацию, но получают собственное оформление и компоненты без копирования всего приложения. Тема и брендинг — данные сайта, а не выбор на этапе сборки: логотип, цвета, шрифты, навигация и футер правятся в админке для каждого сайта, а темы могут наследовать блоки от родительской. Для платформы с десятками похожих сайтов это позволяет поддерживать общий код и одновременно сохранять различия между проектами.

Из практичного: SEO-поля (meta title, description, соцкартинка) реально попадают в разметку страницы, есть управляемые 301-редиректы, а загружаемые картинки пережимаются и конвертируются в WebP.

Почему Nuxt, если Payload работает на Next.js

Это особенно интересно на фоне Payload 4 — четвёртая версия пока в бете — и появления framework adapters, которые позволяют запускать сам Payload поверх другого поддерживаемого фреймворка, например TanStack Start.

Polysite построен на Payload 3, поэтому административная панель по-прежнему живёт в Next.js. Но публичный сайт от этого не обязан быть приложением Next.js: Nuxt получает содержимое из Payload как из headless CMS.

Nuxt → Payload API (REST / GraphQL) → PostgreSQL

Это классическая headless-схема, и Polysite показывает её целиком: отдельный сервер контента, отдельный клиент на другой технологии и прокси, который разруливает домены.

Инфраструктура тоже входит в проект

Автор уделил внимание не только интерфейсу. Стек разворачивается через Docker Compose на одной VM: Caddy с автоматическим HTTPS и контейнеры CMS, фронтенда, базы данных и бэкапа.

Скрипт деплоя перед переключением делает бэкап, прогоняет миграции и переключает сервисы по одному за проверками здоровья; если проверка не прошла — откатывается автоматически.

Бэкапы базы и медиа делаются каждую ночь, у них настраиваются срок хранения, шифрование и off-site копия, а отдельная еженедельная задача доказывает, что последний бэкап действительно восстанавливается.

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

Плагины и темы вынесены в отдельные репозитории и подключаются добавлением папки. В плагинах — новости и статьи, доставка писем, аналитика, уведомления, SSO и двухфакторная аутентификация, несколько языков на сайт, поиск по сайту и импортёр из WordPress. Отдельный репозиторий собрал рецепты развёртывания: Helm-чарт для Kubernetes, свои прокси (nginx, Apache, Traefik), cloud-init для одной VM. Есть и CLI в раннем превью — пакет @polysite/cli в npm.

Мелочи, которые говорят о зрелости подхода: телеметрии в проекте нет вовсе, на https-инсталляции CMS отказывается стартовать с плейсхолдерными секретами, а первый администратор создаётся по одноразовому setup-токену.

Где такой подход пригодится

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

Вместо десятка независимых CMS — одна система пользователей, единый процесс обновления и общая инфраструктура. При этом сайты могут иметь разные домены, содержимое и оформление.

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

Важное ограничение — лицензия

Polysite опубликован с исходным кодом, но это не open source в определении OSI. Лицензия называется Polysite Source-Available License (версия 1.0), лицензиар — Quick Support Today Inc.

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

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

Поэтому воспринимать проект как обычный MIT-шаблон Payload, который можно без дополнительных условий взять за основу клиентской платформы, не следует. А вот изучать архитектуру, разворачивать систему и использовать её разрешёнными лицензией способами можно уже сейчас.

Насколько этому доверять

Проекту от первого коммита до публикации этой статьи — девять дней, автор один, статус pre-1.0 и ни одного релиза. Как проверенной годами платформой для сотен сайтов пользоваться им рано.

При этом инженерная культура в репозитории видна: подробный ARCHITECTURE.md с потоками запросов, моделью данных и списком реальных багов, найденных при разработке; smoke-, E2E-, backup- и deploy-тесты; линт и unit-тесты в CI и pre-commit-хуке.

Мы бы смотрели на Polysite в первую очередь как на готовый образец multi-tenant архитектуры на Payload: что именно вынесено в общее ядро, как устроены проверки доступа и как организована публикация на несколько доменов.

Что в итоге

одна админка Payload 3 на несколько независимых сайтов с собственными доменами;
изоляция контента, медиа и пользователей по сайтам, динамические роли из админки;
блочный конструктор с живым превью, черновики, версии, отложенная публикация;
темы на Nuxt Layers с выбором в рантайме, SEO-поля и 301-редиректы;
публичная часть на Nuxt 4 — CMS и фронтенд развиваются независимо;
Docker Compose, деплой с проверками здоровья и автоматическим откатом, ночные бэкапы с еженедельной проверкой восстановления.

Polysite интересен прежде всего как готовый пример архитектуры многосайтового проекта на Payload CMS. И он хорошо показывает преимущество headless-подхода: Payload может быть общей системой управления контентом для всей организации, даже если сами сайты построены совсем не на Next.js.

Источники

https://github.com/polysites/polysite— репозиторий Polysite (ядро и документация)
https://github.com/polysites/polysite/blob/main/LICENSE.md— текст лицензии Polysite Source-Available
https://github.com/polysites/polysite-themes— репозиторий тем (Nuxt Layers)
https://github.com/polysites/polysite-plugins— репозиторий плагинов
https://github.com/polysites/polysite-deploy— рецепты развёртывания

Назад в блог