Strapi или Payload: что выбрать

Strapi 5 и Payload 3 обе бесплатны, обе на Node.js и TypeScript, обе отдают контент по REST и GraphQL. Разница в одном: Strapi это отдельный сервер с конструктором типов в интерфейсе, а Payload это библиотека, которая живёт внутри вашего приложения Next.js и описывается кодом. У нас в работе два сайта на Strapi с фронтом на Next.js, портал заявок и интернет-магазин на Payload, поэтому ниже сравнение по тому, что реально влияет на проект, а не по списку фич с сайтов производителей.

Коротко, если некогда читать

• Типы контента хочется собирать в конструкторе, а не кодом, фронт может быть на чём угодно, нужен готовый маркетплейс плагинов: Strapi.
• Всё на Next.js, одна кодовая база и один деплой, в проекте больше логики, чем контента (личный кабинет, заявки, роли): Payload.
• Сидите на Strapi 4 и думаете, обновляться или переезжать: считайте оба варианта, разница часто небольшая.

Таблица сравнения

Версии на 30 сентября 2026: Strapi 5.56, Payload 3.90.

Где разница чувствуется на практике

Кто заводит поля

В Strapi поля и типы собираются мышкой в Content-Type Builder, а результат ложится в JSON-файлы проекта. Оговорка, про которую часто забывают: конструктор доступен только в режиме разработки (по документации Strapi он "Available in Development environment only"). На боевом сервере с NODE_ENV=production он открывается только для просмотра, потому что изменение схемы требует пересборки и перезапуска. То есть новое поле в Strapi всё равно появляется через разработчика: он добавляет его на локальной копии, коммитит JSON и выкатывает. Плюс Strapi здесь в том, что для этого не нужно писать код, и прототип структуры контента можно накликать за час.

В Payload любое поле это строчки в конфиге коллекции. Зато схема лежит в git, проходит код-ревью и одинаково разворачивается на тесте и на проде. На портале заявок у нас обязательность фото (талон, акт, шильдик) описана прямо в схеме, и обойти её через админку нельзя.

Сколько сервисов деплоить

Типовой проект на Strapi у нас выглядит так: контейнер Strapi, контейнер Next.js, Postgres, Nginx. Два домена: сайт и админка. Две сборки, два набора переменных окружения, и отдельная головная боль, когда фронт внутри Docker ходит в Strapi по внешнему домену вместо имени контейнера. На эту тему у нас есть отдельный разбор ошибок ECONNREFUSED и ENOTFOUND.

На Payload это один контейнер Next.js и база. Админка открывается по /admin на том же домене. Серверные компоненты читают данные через Local API, без HTTP-запроса к самому себе.

Логика сложнее контента

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

В интернет-магазине Плавательный.рф на Payload у нас три части: Next.js с Payload (каталог, статьи, контент, админка), отдельный бэкенд на FastAPI для интеграций (МойСклад, эквайринг, доставка, SMS) и мобильные приложения на Capacitor поверх того же сайта. Payload здесь закрывает контент и админку, а не пытается быть всем.

Плагины и экосистема

У Strapi маркетплейс больше, и для типовых задач (SEO-поля, импорт-экспорт, S3, sitemap) обычно есть готовый плагин. Минус в том, что при переходе на v5 все плагины v4 перестали работать, и часть сообществом до сих пор не переписана.

У Payload официальные плагины покрывают SEO, формы, поиск, редиректы, вложенные документы, мультитенантность, импорт-экспорт, Stripe и e-commerce, а хранение файлов в S3 делается штатным адаптером. Сторонних меньше, но чаще всего плагин и не нужен: нужное поле или хук пишутся за час.

Обновления

Переход Strapi 4 → 5 это отдельный проект: меняется формат ответа REST (уходит data.attributes), числовой id заменяется на documentId, Entity Service на Document Service, плагины переписываются. У нас два сайта на Strapi 4, и обновление каждого мы считаем как отдельную работу. Подробно про сроки и что ломается написали на strapi.expert/obnovlenie-strapi-4-do-5.

Payload 3 с ноября 2024 живёт в ветке 3.x, и обновления внутри неё у нас проходят как обычный pnpm update с прогоном миграций базы. Оговорка: перед подключением Payload к существующему проекту на Next.js пришлось обновить сам Next.js и закрыть уязвимости в зависимостях, на старой версии Payload не ставился.

Хостинг и деньги

Обе системы на своём сервере бесплатны. Разница в платных функциях: в Strapi Live Preview, Releases и история контента вынесены в план Growth за 45 долларов в месяц на 3 места. В Payload live preview и версии в ядре.

Облако: Strapi Cloud стартует с 35 долларов в месяц (29 при годовой оплате) за 100 000 запросов к API и 50 ГБ файлов. Из России оплатить его картой не получится, так что для наших клиентов это в любом случае VPS. Payload Cloud после покупки Figma новые проекты временно не принимает, и это тоже не аргумент: Payload разворачивается на любом сервере с Node.js.

Когда что брать

Берите Strapi, если:

• структуру контента удобнее собирать в конструкторе на локальной копии, чем описывать кодом;
• фронтов несколько и они на разных технологиях (сайт на Nuxt, приложение на Flutter);
• нужна MySQL или MariaDB, потому что так решено в компании;
• нужна поддержка от вендора и план Enterprise с аудитом и SSO.

Берите Payload, если:

• фронт на Next.js и вы не хотите второй сервер;
• в проекте личный кабинет, заявки, роли, статусы, а не только страницы;
• команда разработчиков ведёт схему в git и не хочет кликать в конструкторе;
• нужна MongoDB.

Если сомневаетесь, напишите нам, что за проект, и мы за день скажем, на чём его делать и во что это обойдётся. Разработка на Strapi у нас на strapi.pro, на Payload на payload.agency, а если вы уже на Strapi 4 и думаете, обновляться или переезжать, начните со strapi.expert.