Payload CMS: когда выбирать вместо Strapi и Sanity

Payload CMS - правильный выбор, если команда строит новое приложение на Next.js, хочет держать схему контента прямо в TypeScript-коде и не готова платить SaaS-подписку за каждого редактора. Strapi выигрывает, когда нужна классическая архитектура “CMS отдельно, фронтенд отдельно” на SQL-базе без привязки к конкретному фреймворку. Sanity лучше, если для команды важнее готовый редакторский интерфейс с совместным редактированием в реальном времени, чем полный контроль над инфраструктурой.

Коротко: у всех трёх есть открытый код или щедрый бесплатный тариф, но модель развёртывания и владения данными у них принципиально разная. Именно она должна определять выбор - а не список функций в маркетинговой таблице на сайте вендора.

В июне 2025 года компанию Payload купила Figma - и это не рядовая новость для рынка headless CMS. Официальный анонс Figma подтверждает: вся команда Payload перешла в Figma, лицензия MIT и исходный код остаются открытыми, но управляемый хостинг Payload Cloud перестал принимать новые проекты. Для команд, которые выбирают CMS сегодня, self-hosted развёртывание - не опциональный апгрейд на будущее, а единственный путь с первого дня.

Это меняет расчёт при выборе. Раньше можно было начать на Payload Cloud и решить вопрос инфраструктуры позже. Сейчас инфраструктуру и DevOps-время нужно закладывать в бюджет проекта сразу. В этой статье - конкретные критерии, когда Payload CMS выигрывает у Strapi и Sanity, а когда проигрывает, с разбором архитектуры, деплоя и реальной стоимости владения.

Команда, которая запускает продуктовый сайт или маркетинговый лендинг на Next.js, обычно выбирает CMS в последнюю очередь - уже после того как стек фронтенда определён. Если выбор CMS не соответствует архитектуре фронтенда, разработчик тратит недели на прослойки: отдельный сервер для API, кастомную авторизацию, синхронизацию типов между схемой CMS и TypeScript-типами приложения. Payload закрывает именно этот разрыв - ценой того, что CMS становится частью бэкенда приложения, а не независимым сервисом.

Payload CMS: open-source headless CMS и full-stack фреймворк на TypeScript, который описывает контентные модели в коде и генерирует из них REST/GraphQL API и админ-панель. С версии 3.x Payload устанавливается прямо в проект Next.js как часть приложения, а не как отдельный сервис.

Сравнение: Payload CMS, Strapi и Sanity

Архитектура и деплой: три разные модели владения

Каждая из трёх CMS решает вопрос “где живёт бэкенд” по-своему, и это определяет затраты на инфраструктуру сильнее, чем любая функция из маркетингового списка.

Payload с версии 3.x коллоцирован с Next.js: админ-панель, REST API, GraphQL-эндпоинт и Local API работают в одном процессе с фронтендом. Local API - это набор функций Payload, которые можно вызывать прямо из React Server Components без HTTP-запроса внутри одного процесса. Это убирает сетевой хоп между рендерингом страницы и получением данных, что напрямую снижает время до первого байта.

Обратная сторона: Payload требует полноценный Node.js-раннер, а не только статическую генерацию. Задеплоить админ-панель на чисто статический хостинг нельзя - нужен Vercel с serverless-функциями, Railway, Render или собственный сервер с Docker.

Strapi работает как независимый API-сервер: фронтенд на любом фреймворке обращается к нему по HTTP. Это классическая headless-архитектура - Strapi можно развернуть на одном сервере, а фронтенд деплоить отдельно, хоть на статический CDN. Гибкость выше, но добавляется сетевой слой между приложением и данными на каждый запрос без кеша.

Sanity убирает вопрос инфраструктуры целиком: Studio, API и CDN для ассетов размещены на стороне Sanity. Разработчику нужно только настроить схему и подключить SDK во фронтенде. Плата за это - зависимость от инфраструктуры вендора и проприетарный формат хранения.

Когда выбирать Payload CMS

Payload CMS оправдан, если выполняется большинство условий:

• проект строится на Next.js 15+ с самого начала, а не мигрирует со старого стека
• команда ценит типобезопасность на всех уровнях: от схемы коллекции до пропсов компонента
• нужен полный контроль над бизнес-логикой на уровне API - кастомные хуки при сохранении документа, сложная авторизация по ролям
• инфраструктура и её поддержка уже есть в компании или закладывается в бюджет с первого дня
• данные должны храниться в стандартном SQL или MongoDB без риска vendor lock-in

По данным поиска на GitHub, число звёзд репозитория Payload выросло с 8 200 до 24 300 за последний год - это самый резкий рост среди трёх CMS, и он совпадает по времени с ростом популярности Next.js App Router. Разработчики, которые начинают новые проекты на Next.js 15, всё чаще находят Payload как нативный вариант CMS для этого стека.

Когда выбирать Strapi

Strapi остаётся сильным выбором, если:

• фронтенд не привязан к Next.js - команда работает с Nuxt, SvelteKit, Astro или мобильным приложением
• предпочтительна реляционная SQL-база данных без документной модели
• нужен быстрый локальный старт разработки без внешних зависимостей
• в компании есть инженеры, готовые поддерживать отдельный API-сервер как часть инфраструктуры
• важно сохранить архитектурное разделение “бэкенд отдельно от фронтенда” даже при смене фронтенд-фреймворка в будущем

Подробный разбор Strapi в связке с Astro и Next.js, включая ценообразование и модуль @nuxtjs/strapi, разобран в статье Sanity vs Contentful vs Strapi: выбор Headless CMS для B2B-сайта.

Когда выбирать Sanity

Sanity остаётся лучшим вариантом, если:

• контент-команда больше 3-5 человек и им нужно одновременно редактировать одни и те же документы
• у компании нет ресурса на инфраструктуру и DevOps вообще - ни разового запуска, ни последующей поддержки
• контентная модель сложная и требует гибких запросов - GROQ справляется с фильтрацией и проекциями лучше, чем REST-эндпоинты Payload или Strapi
• редакторам важен готовый визуальный интерфейс с превью в реальном времени без доработки админ-панели разработчиком

Если команда уже сравнивает Sanity, Contentful и Strapi между собой без Payload в списке - это отдельный разбор с таблицей цен и разбором по стекам в статье Sanity vs Contentful vs Strapi.

Самостоятельный хостинг против SaaS: что реально входит в стоимость

Самостоятельный хостинг (self-hosted): размещение CMS на собственном сервере или облачной инфраструктуре, при котором команда несёт полную ответственность за обновления, резервные копии, мониторинг и безопасность.

Сам Payload бесплатен - лицензия MIT не ограничивает число записей, пользователей или API-запросов. Но self-hosted не означает бесплатно в целом. Инфраструктура для продакшен-проекта на Payload обычно начинается от 10 евро в месяц за минимальный сервер и растёт вместе с трафиком и объёмом медиафайлов.

Разница между “бесплатной лицензией” и “реальной стоимостью владения” - это DevOps-время: настройка CI/CD, обновление зависимостей при выходе новых версий Payload, мониторинг падений сервиса, резервное копирование базы данных. Для команды без выделенного DevOps эти задачи ложатся на того же разработчика, который пишет фичи, и стоят реального времени, даже если не отражены в счёте за хостинг.

Sanity в этом сравнении работает иначе: Growth-тариф на уровне 99 долларов в месяц включает CDN для ассетов, автоматическое масштабирование и отсутствие инфраструктуры на стороне клиента вообще. Для небольшой команды без DevOps это может быть дешевле в реальной стоимости владения, чем self-hosted Payload или Strapi, даже при более высокой номинальной цене подписки.

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

Payload после покупки Figma: что изменилось для новых проектов

Покупка Payload компанией Figma в июне 2025 года не затронула открытый код: репозиторий на GitHub остаётся публичным, лицензия MIT не изменилась, и команда Payload продолжает развивать проект уже внутри Figma. Для существующих пользователей Payload Cloud ничего резко не сломалось - действующие проекты продолжают работать.

Изменение касается новых проектов: Payload Cloud, управляемый хостинг от самой компании, закрыт для новых клиентов. Раньше можно было запустить проект на Payload Cloud по цене от 35 долларов в месяц за Standard-план и не думать об инфраструктуре вообще. Сейчас этой опции для новых пользователей нет - self-hosted развёртывание стало не альтернативой, а единственным путём.

Публично известно, что команда Payload сейчас работает над продуктом, который может стать частью направления “CMS для дизайнеров” внутри Figma - мостом между дизайн-макетами и живым контентом на сайте. Для инженерных команд, выбирающих CMS в middle-2026, это означает: закладывать инфраструктуру Payload нужно с первого дня проекта, а не рассчитывать на managed-хостинг как на подстраховку.

Реальный кейс: запуск B2B-сайта на Next.js и Payload

В типовом проекте запуска маркетингового B2B-сайта на Next.js 15 с Payload как встроенной CMS настройка первых 5-7 коллекций - страницы, статьи, авторы, медиа, редиректы - занимает 3-5 рабочих дней у разработчика с опытом Next.js. Схема коллекций описывается в TypeScript, и через несколько часов после первого коммита уже доступна рабочая админ-панель с формами для всех типов контента.

import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'publishedAt',
      type: 'date',
    },
    {
      name: 'content',
      type: 'richText',
    },
  ],
}

Инфраструктура для такого проекта - инстанс PostgreSQL за 15-25 долларов в месяц плюс контейнер приложения на Railway или Render за 20-30 долларов в месяц. Итоговая инфраструктурная стоимость держится в диапазоне 35-55 долларов в месяц против 99 и более долларов на Growth-тарифе Sanity или нескольких сотен долларов на тарифах Contentful. При этом схема данных лежит в обычных SQL-таблицах и не требует экспорта через API при смене платформы в будущем - в отличие от проприетарного формата Sanity.

Если проект стартует с нуля, а не переезжает со старой платформы, экономия на этапе выбора архитектуры особенно заметна: не нужно платить за функции SaaS-CMS, которые команда из 2-3 человек физически не использует, вроде сложных workflow согласования на 20 редакторов.

Для кого подходит Payload CMS

Payload CMS - логичный выбор для стартапов и продуктовых команд, которые уже выбрали Next.js как основной фреймворк и хотят получить бэкенд, авторизацию и админ-панель из коробки без сборки этого вручную. Хорошо подходит инженерным командам от 2 человек, где один разработчик может одновременно поддерживать и фронтенд, и схему CMS, не переключаясь между разными языками запросов и разными репозиториями.

Payload менее подходит крупным редакциям с 15+ нетехническими редакторами, которым нужен полированный интерфейс уровня Sanity Studio и совместное редактирование в реальном времени - для этого сценария разрыв в опыте редактора всё ещё заметен.

Часто задаваемые вопросы

Что такое Payload CMS простыми словами?

Payload CMS - это open-source фреймворк на TypeScript, который берёт на себя рутину бэкенда: базу данных, REST и GraphQL API, авторизацию, загрузку файлов и админ-панель для редакторов. Разработчик описывает структуру контента - коллекции и поля - в коде, а Payload генерирует из этого описания рабочую систему управления. С версии 3.x Payload устанавливается прямо внутрь проекта Next.js и работает в одном процессе с приложением, а не как отдельный сервис.

Payload CMS бесплатный?

Сам продукт - да, лицензия MIT позволяет использовать Payload бесплатно без ограничений на количество записей, пользователей или API-запросов. Расходы возникают на стороне инфраструктуры: сервер, база данных, резервное копирование и время на поддержку. Managed-хостинг Payload Cloud, который раньше снимал этот вопрос за фиксированную месячную плату, с середины 2025 года закрыт для новых проектов после покупки компании Figma.

Чем Payload CMS принципиально отличается от Strapi?

Главное отличие - модель развёртывания. Strapi работает как отдельный API-сервер, независимый от фронтенда: его можно развернуть на одном сервере, а сайт на другом, и они общаются по HTTP. Payload с версии 3.x коллоцирован с Next.js-приложением - работает в одном процессе, использует Local API для прямых вызовов без сети и требует именно Next.js как фронтенд-фреймворк. Strapi гибче по выбору фронтенда, Payload даёт более тесную интеграцию и типобезопасность конкретно с Next.js.

Нужен ли отдельный сервер для Payload CMS?

Да. Payload - это full-stack фреймворк, который требует полноценного Node.js-окружения, а не только статической генерации. Развернуть его можно на Vercel с serverless-функциями, на Railway, Render или на собственном сервере через Docker, но чисто статический хостинг без бэкенда не подойдёт. Это отличает Payload от Sanity, где вся инфраструктура CMS размещена на стороне вендора и разработчику не нужен отдельный сервер вообще.

Можно ли перенести данные с Sanity на Payload или наоборот?

Технически возможно, но объём работы разный в зависимости от направления. Payload и Strapi хранят данные в стандартных SQL-таблицах или MongoDB-коллекциях, поэтому перенос между ними ближе к обычной миграции базы данных. Перенос данных из Sanity сложнее: контент хранится в проприетарном NDJSON-формате, а GROQ-запросы и структуры Portable Text не переносятся напрямую в схему другой CMS. Экспортировать данные из Sanity через API можно, но перестроить схему и все запросы под новую платформу - это отдельный проект на несколько недель, а не разовый экспорт.

Если вы выбираете CMS для нового проекта на Next.js или сравниваете реальную стоимость self-hosted и SaaS-вариантов - опишите задачу команде Exceltic.dev. Разберём архитектуру под ваш стек и посчитаем инфраструктурные затраты на конкретном объёме контента.