Payload CMS: headless CMS на TypeScript — альтернатива Strapi

Ты собрал лендинг на Next.js вместе с Claude Code, выложил его на Vercel, и теперь хочешь добавлять новые статьи или товары без необходимости каждый раз просить ИИ переписывать код. Решение очевидно — подключить headless CMS, чтобы контент жил в базе данных, а сайт сам подтягивал изменения. Если ты уже смотрел в сторону Strapi, но хочешь вариант, который роднее Next.js и TypeScript, стоит присмотреться к Payload CMS. Ниже — что такое Payload CMS, чем она отличается от Strapi, почему её удобно использовать в стеке курса и когда она действительно выигрывает.

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

Payload CMS — это open-source headless CMS, то есть «безголовая» система управления контентом. Как и Strapi, она отделяет место, где хранится и редактируется контент, от самого сайта. Редактор заходит в панель администратора, добавляет статью, меняет цену товара или загружает картинку, а фронтенд — например, твой Next.js-сайт — получает эти данные через API и отрисовывает страницу.

Термин «headless» буквально означает «без головы»: у CMS нет своей публичной части, только «тело» — база данных, админка и API. Ты сам решаешь, как выглядит сайт, в каком фреймворке он написан и на каких устройствах работает. Это главное отличие от классических CMS вроде WordPress, где админка, темы и публичный сайт живут в одной связке.

В Payload CMS всё строится вокруг двух понятий: коллекции и глобальные настройки.

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

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

Главная идея Payload CMS в том, что конфигурация — это тоже код. Вместо того чтобы щёлкать мышкой по экранной форме и надеяться, что все разработчики запомнили названия полей, ты описываешь структуру данных на TypeScript. Это даёт автодополнение в редакторе, защиту от опечаток и уверенность, что схема на production совпадает с тем, что написано в репозитории.

Чем Payload принципиально отличается от Strapi, а не дублирует его

С первого взгляда Payload CMS и Strapi делают похожие вещи: обе self-hosted, обе дают админку и API, обе позволяют хранить контент отдельно от фронтенда. Но подход к работе у них разный. Если Strapi в первую очередь настраивается через графический интерфейс, то Payload CMS — это TypeScript-first инструмент, где схема данных живёт в коде.

Strapi: конфигурация через админку

В Strapi большая часть моделирования данных происходит в Content-Type Builder: ты заходишь в админку, создаёшь новый тип контента, добавляешь поля, выбираешь их тип, настраиваешь связи. Это удобно, когда хочется быстро собрать прототип без редактирования кода. Редакторы и менеджеры могут сами расширять модели, не привлекая разработчика.

Strapi написан на JavaScript и исторически развивался как отдельное Node.js-приложение. Оно запускается на своём порту, имеет свою базу данных и общается с фронтендом по REST или GraphQL. Это зрелая экосистема с плагинами, большим сообществом и множеством интеграций.

Payload CMS: конфигурация как код

Payload CMS построена на TypeScript с самого начала. Вместо кликов в админке ты пишешь файл конфигурации, где объявляешь коллекции, поля, права доступа, хуки и валидацию. Пример упрощённой коллекции статей может выглядеть так:

import { CollectionConfig } from 'payload';

export const Articles: CollectionConfig = {
  slug: 'articles',
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'cover', type: 'upload', relationTo: 'media' },
    { name: 'content', type: 'richText' },
    { name: 'publishedAt', type: 'date' },
  ],
};

Этот код говорит Payload CMS: «у меня есть коллекция articles, у каждой статьи есть заголовок, slug, обложка, контент и дата публикации». На основе этого описания система создаёт:

• таблицу или коллекцию в базе данных;
• форму в админ-панели с нужными полями;
• REST и GraphQL endpoints для чтения и записи;
• TypeScript-типы, которые можно использовать на фронтенде.

Почему кодовая конфигурация важна

Когда схема описана кодом, она проходит через все привычные инструменты разработки:

• Git. Любое изменение структуры данных — это коммит. Можно увидеть, кто и когда добавил поле, откатить изменение или обсудить его в пул-реквесте.
• Автодополнение. В TypeScript редактор сам подсказывает доступные поля, их типы и названия. Это особенно ценно при работе с Claude Code: ИИ видит ту же структуру, что и ты, и не угадывает имена полей.
• Проверка типов. Если ты переименовал поле, но не обновил компонент, который его читает, TypeScript сразу покажет ошибку. В кликабельной админке такая защита появляется только на уровне документации и договорённостей.
• Переносимость. Конфигурация лежит в репозитории вместе с сайтом. Разворачивать новое окружение или делать резервную копию проще, потому что структура данных описана явно.

Почему это ближе к стеку курса

В курсе skillmake лендинг и приложения собираются на Next.js — том же фреймворке, который используется для фронтенда. Подробнее про Next.js можно прочитать в статье «Лендинг на Next.js с Claude». Payload CMS изначально проектировалась для тесной работы с Next.js, и начиная с Payload CMS 3 она устанавливается прямо внутрь Next.js-приложения, а не поднимается отдельным сервисом.

Один репозиторий вместо двух

В классической схеме со Strapi у тебя два приложения: один проект на Next.js отвечает за сайт, другой проект на Strapi — за админку и API. Они живут на разных портах, деплоятся отдельно, требуют отдельной настройки CI/CD, переменных окружения и мониторинга. Для новичка это лишний уровень сложности: нужно помнить, какой сервер отвечает за что, и не перепутать URL при запросах.

Payload CMS 3 встраивается в папку app Next.js. Админка работает как отдельный маршрут внутри того же приложения, а API генерируется в том же процессе. Получается один репозиторий, один фреймворк, один сервер, одна инструкция по запуску. Это упрощает разработку и снижает количество контекста, который нужно держать в голове.

Общие типы и единый язык

Поскольку и фронтенд, и бэкенд написаны на TypeScript в рамках одного проекта, типы данных можно использовать на обеих сторонах. Если в конфигурации Payload CMS есть коллекция articles с полем title, то на фронтенде TypeScript знает, что у объекта статьи есть title, и подскажет его автодополнением. Это уменьшает количество ошибок и ускоряет работу с Claude Code: ассистент видит структуру проекта целиком и генерирует код, который согласован с данными.

Тот же процесс деплоя

Next.js-приложение с Payload CMS деплоится на те же платформы, что и обычный Next.js-сайт: Vercel, Railway, Docker-контейнер на своём сервере. Не нужно учить отдельный способ развёртывания для CMS. Это важно, когда ты только начинаешь: чем меньше разных технологий, тем меньше точек, где что-то может пойти не так.

Удобство для ИИ-ассистента

Когда ты работаешь с Claude Code, ассистент читает файлы проекта. В случае с Payload CMS вся схема данных лежит в виде понятного TypeScript-кода: видны названия коллекций, полей, типы, связи. Claude может предложить запрос к API, зная точные имена полей, или помочь добавить новую коллекцию, скопировав структуру существующей. В кликабельной CMS часть логики скрыта в базе данных и админке, и ИИ не видит её напрямую.

Связь с правилом «контент в БД, а не в коде»

Одно из важных правил, которое мы разбирали в статье про Strapi, звучит так: контент должен храниться в базе данных, а не в коде. Payload CMS решает ту же задачу, но своим способом.

Скажем, ты ведёшь блог о своих проектах и каждую новую статью добавляешь вручную в HTML-файл. Ты открываешь код, копируешь разметку предыдущей статьи, меняешь текст, пути к картинкам, мета-теги, и только потом деплоишь сайт заново. Если статей мало, это терпимо. Но стоит добавлять их хотя бы раз в неделю, процесс превращается в рутину, а риск случайно сломать вёрстку растёт.

Headless CMS меняет эту схему:

1. Ты один раз описываешь в коде, как устроена статья: какие у неё поля, какие обязательные, какие типы данных.
2. Редактор добавляет статью через админку: заполняет форму, загружает картинки, выбирает дату.
3. Сайт при загрузке страницы запрашивает данные из базы и отрисовывает их по шаблону.

Теперь, чтобы опубликовать новый материал, не нужно трогать код и пересобирать весь сайт. Достаточно зайти в админку, нажать «Создать» и сохранить. Это особенно важно, когда сайтом пользуются не только разработчики, но и редакторы, маркетологи или заказчики.

Пример из жизни курса

Например, ты делаешь страницу с отзывами выпускников курса. Без CMS ты хранишь каждый отзыв в JSX-файле: имя, фото, текст, ссылка на проект. Чтобы добавить новый отзыв, приходится редактировать код и деплоить сайт. С Payload CMS ты создаёшь коллекцию testimonials с полями name, photo, quote, projectUrl. После этого менеджер курса сам добавляет отзывы в админке, а сайт автоматически их подхватывает.

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

Когда выбрать Payload, а когда Strapi

Ни один инструмент не универсален. Выбор между Payload CMS и Strapi зависит от того, кто будет работать с системой, какой стек уже используется и как важна типобезопасность.

Выбирай Payload CMS, если:

• Ты уже пишешь на TypeScript и Next.js. Payload CMS 3 становится продолжением твоего проекта, а не отдельным сервисом.
• Хочешь держать схему данных в коде. Это удобно для команд, которые ценят ревью кода, автодополнение и проверку типов.
• Работаешь с Claude Code или другими ИИ-ассистентами. TypeScript-конфигурация легче читается ассистентом, и он реже ошибается в названиях полей.
• Планируешь делать не просто блог, а полноценное приложение с пользователями, правами доступа, загрузкой файлов и кастомной логикой.
• Хочешь один процесс деплоя и один репозиторий для фронтенда и админки.

Выбирай Strapi, если:

• Нужно быстро запустить админку без написания конфигурации в коде. Content-Type Builder позволяет собрать модели мышкой.
• Работают не-разработчики, которым удобнее кликать в интерфейсе, чем редактировать TypeScript.
• Важна зрелая экосистема плагинов: SEO, комментарии, интернационализация, интеграции с внешними сервисами.
• Проект не на Next.js, и ты хочешь отдельный бэкенд, который отдаёт данные любому фронтенду.
• Команда привыкла к классической модели «фронтенд + отдельный API».

Сравнительная таблица

Как это выглядит на уровне архитектуры

Архитектура Payload CMS во многом повторяет идею Strapi, но с одним важным отличием: в Payload CMS 3 фронтенд и CMS живут в одном Next.js-приложении.

Компоненты системы

1. База данных. Обычно PostgreSQL или MongoDB. В ней хранятся коллекции, пользователи, загруженные файлы, настройки. Про выбор базы данных для новичка мы писали в статье «Базы данных для новичка».
2. Next.js-приложение с Payload CMS. Внутри одного проекта работают публичные страницы сайта и админ-панель Payload. Админка доступна по отдельному маршруту, например /admin.
3. API. Payload генерирует REST и GraphQL endpoints автоматически на основе описанных коллекций. Фронтенд запрашивает данные так же, как если бы общался с отдельным бэкендом.
4. Браузер пользователя. Загружает страницы Next.js, которые получают контент из API или напрямую из базы через серверные компоненты.

Схема потока данных

Браузер
   │
   ▼
Next.js-приложение (сайт + Payload CMS)
   │
   ├── Публичные страницы (/blog, /products)
   └── Админ-панель (/admin)
   │
   ▼
База данных (PostgreSQL / MongoDB)

Когда редактор заходит в админку и сохраняет статью, данные уходят в базу. Когда посетитель открывает страницу блога, Next.js либо делает серверный запрос к Payload, либо использует REST/GraphQL endpoint. Разница со Strapi в том, что запрос не уходит на внешний сервер: всё происходит внутри одного приложения.

Где размещать базу данных

Для учебных и небольших проектов базу данных можно поднять локально в Docker или использовать облачный сервис вроде Neon, Supabase PostgreSQL или MongoDB Atlas. Для production важно настроить резервное копирование, миграции и доступы. Payload CMS использует миграции, чтобы структура базы данных соответствовала конфигурации в коде.

Плюсы и минусы Payload CMS

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

Что делает Payload CMS особенно удобной

Нативная интеграция с Next.js. Payload CMS 3 работает внутри приложения Next.js, используя App Router. Админка — это отдельный маршрут, а публичные страницы остаются обычными страницами Next.js. Не нужно запускать второй сервер и настраивать CORS.

Единые типы данных. Поскольку конфигурация и фронтенд живут в одном репозитории, типы сущностей можно импортировать и на сервере, и на клиенте. Это снижает количество ошибок, когда ты меняешь структуру данных.

Конфигурация под контролем Git. Любое изменение схемы — это коммит. Можно посмотреть историю, откатить правку, обсудить в пул-реквесте. Для команд это прозрачнее, чем изменение моделей через админку.

Локальный API. В серверных компонентах Next.js можно обращаться к данным напрямую, без HTTP-запроса. Это ускоряет рендеринг и упрощает код.

Гибкость доступов и хуков. Права доступа, валидация полей, хуки перед сохранением документа — всё описывается кодом. Это даёт точный контроль над тем, кто и что может делать с контентом.

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

Ограничения, о которых стоит знать

Более высокий порог входа. Если ты плохо знаком с TypeScript или Next.js, первые шаги могут показаться сложнее, чем в Strapi. Нужно понимать, как работают импорты, типы и конфигурационные файлы.

Меньшая экосистема плагинов. У Strapi больше готовых плагинов, интеграций и примеров от сообщества. В Payload CMS часто приходится писать кастомные решения самому.

Изменения в админке требуют деплоя. Чтобы добавить новое поле, нужно изменить код и перезапустить приложение. В Strapi Content-Type Builder позволяет менять схему прямо в работающей админке, хотя в production это тоже требует осторожности.

Самостоятельная поддержка инфраструктуры. Ты отвечаешь за обновления безопасности, резервные копии и мониторинг. Это не сложно для небольшого проекта, но требует дисциплины.

Практический пример: коллекция «Статьи» в коде

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

Описание коллекции

import { CollectionConfig } from 'payload';

export const Articles: CollectionConfig = {
  slug: 'articles',
  admin: {
    useAsTitle: 'title',
  },
  access: {
    read: () => true,
    create: ({ req: { user } }) => Boolean(user),
    update: ({ req: { user } }) => Boolean(user),
    delete: ({ req: { user } }) => Boolean(user),
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    {
      name: 'category',
      type: 'select',
      options: ['Объяснялка', 'Практика', 'Бизнес'],
      required: true,
    },
    { name: 'cover', type: 'upload', relationTo: 'media' },
    { name: 'excerpt', type: 'textarea', required: true },
    { name: 'content', type: 'richText' },
    { name: 'publishedAt', type: 'date', required: true },
  ],
};

Здесь мы объявили, что у статьи есть заголовок, уникальный slug, категория, обложка, краткое описание, контент и дата публикации. Поле access задаёт простые правила: читать статьи может кто угодно, а создавать, редактировать и удалять — только авторизованные пользователи. Payload CMS на основе этого кода создаст таблицу в базе данных, форму в админке и API.

Запрос данных на фронтенде

В Next.js можно получить статьи, обратившись к API Payload:

async function getArticles() {
  const res = await fetch(`${process.env.NEXT_PUBLIC_PAYLOAD_URL}/api/articles`, {
    next: { revalidate: 60 },
  });
  if (!res.ok) throw new Error('Не удалось загрузить статьи');
  return res.json();
}

Этот код похож на запрос к любому другому API. Разница в том, что благодаря TypeScript ты знаешь точные названия полей и не ошибёшься в articles или publishedAt.

Работа с типами

Если в проекте настроена генерация типов, Payload CMS создаст TypeScript-интерфейсы для всех коллекций. Тогда на фронтенде можно писать:

import { Article } from '@/payload-types';

function ArticleCard({ article }: { article: Article }) {
  return (
    <article>
      <h2>{article.title}</h2>
      <p>{article.excerpt}</p>
    </article>
  );
}

Если ты переименуешь поле excerpt в конфигурации, TypeScript сразу покажет ошибку в компоненте. Это и есть главное преимущество TypeScript-first подхода.

Кастомизация админки

Если стандартной формы недостаточно, Payload CMS позволяет добавлять свои React-компоненты в админку. Например, можно сделать собственный виджет для предпросмотра статьи или кастомное поле для выбора цвета. Это уже более продвинутый уровень, но он показывает, что Payload CMS — не просто CMS, а полноценный фреймворк для бэкенда.

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

Payload CMS платный?

Payload CMS — open-source проект с открытым исходным кодом. Сам движок бесплатен, и ты можешь развернуть его на своём сервере без лицензионных отчислений. Придётся платить только за хостинг, базу данных и домен. Есть и облачная версия от разработчиков Payload, но для учебных проектов обычно достаточно self-hosted варианта. Актуальные тарифы лучше смотреть на официальном сайте Payload CMS.

Нужно ли знать TypeScript, чтобы работать с Payload CMS?

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

Можно ли перенести контент из Strapi в Payload CMS?

Да, но это не одной кнопкой. Обычно пишется скрипт, который забирает данные через API Strapi и создаёт документы в Payload CMS через её API. Перенос требует внимания к полям, типам данных, загрузкам файлов и связям. Для небольших проектов это можно сделать вручную или через простой скрипт на Node.js.

Какую базу данных выбрать?

Payload CMS традиционно хорошо работала с MongoDB и PostgreSQL. В новых версиях, включая Payload CMS 3, добавилась поддержка SQLite через Drizzle, что удобно для локальной разработки и небольших проектов. Для production чаще выбирают PostgreSQL из-за надёжности, миграций и зрелости инструментов. Выбор зависит от масштаба проекта и привычек команды.

Подойдёт ли Payload CMS для лендинга курса?

Да, если лендинг сделан на Next.js. Payload CMS позволит хранить статьи блога, отзывы, часто задаваемые вопросы, цены и другой контент в базе данных, а не в JSX-файлах. Это особенно полезно, когда контент регулярно обновляется. Если же лендинг статичный и обновляется раз в несколько месяцев, для начала может хватить и простых Markdown-файлов.

Что лучше для новичка: Payload CMS или Strapi?

Если новичок только начинает и ещё не уверен в TypeScript — скорее Strapi, потому что там проще начать через визуальный интерфейс. Если новичок уже прошёл модуль с Next.js в курсе и хочет расти в сторону full-stack разработки — Payload CMS даст более цельный опыт и защиту типов. В любом случае обе системы решают одну задачу: отделяют контент от кода.

Заключение + чек-лист

Payload CMS — это TypeScript-first headless CMS, которая ближе всего к стеку Next.js из рассмотренных в курсе инструментов. Вместо того чтобы настраивать структуру данных мышкой, ты описываешь её кодом, получая автодополнение, проверку типов и контроль версий. Payload CMS 3 встраивается прямо в Next.js-проект, поэтому не нужно поддерживать отдельный сервис: фронтенд, админка и API живут в одном приложении.

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

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

Чек-лист «Оценить Payload CMS для своего проекта»

• Проект уже написан или планируется на Next.js.
• Ты готов описывать схему данных на TypeScript, а не только кликать в админке.
• Нужна одна кодовая база для сайта и админки, а не два отдельных сервиса.
• Важна типобезопасность и автодополнение при работе с Claude Code.
• Планируется не только блог, но и пользователи, загрузка файлов или права доступа.
• Выбрана база данных: PostgreSQL, MongoDB или SQLite для старта.
• Есть план по хостингу и резервному копированию базы данных.
• Понятно, кто будет добавлять контент: разработчик или отдельный редактор.
• Рассмотрены альтернативы: Strapi, Sanity, Contentful или Markdown-файлы.
• Готов черновой конфиг хотя бы для одной коллекции, чтобы проверить подход.

Источники

1. Payload CMS — документация: payloadcms.com
2. Strapi — документация: docs.strapi.io