Вышла первая бета Payload CMS 4.0

Разработчики Payload CMS опубликовали 4.0.0-beta.0 — первую бета-версию следующего крупного релиза. Пакет появился на npm 9 октября, релиз на GitHub датирован тем же днём. До этого четвёртая версия несколько недель собиралась в канареечных сборках: всего с июня вышло 40 canary-релизов, в которых постепенно появлялись новая админка, изменения Local API, работа с ИИ через MCP и другие части будущего релиза.

Теперь всё это собрано в первую бету.

До стабильного Payload 4 ещё далеко, и использовать бету в рабочих проектах разработчики пока не рекомендуют: npm-тег latest по-прежнему указывает на 3.90.2. Но основные направления четвёртой версии уже понятны: новая административная панель, ветвление контента, переработанная работа с файлами, развитие MCP и поддержка TanStack.

Ссылка на релиз: https://github.com/payloadcms/payload/releases/tag/v4.0.0-beta.0

Полностью новая админка

Самое заметное изменение Payload 4 — административная панель.

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

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

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

Для Payload это существенное изменение. В третьей версии админка оставалась довольно утилитарным интерфейсом поверх схемы данных. В четвёртой ей уделяют заметно больше внимания как самостоятельному рабочему инструменту.

Content Branching: отдельные ветки теперь не только у кода

Одна из наиболее интересных новых возможностей Payload 4 называется Content Branching.

Идея похожа на привычные разработчикам ветки в Git: изменения контента можно готовить отдельно от основной версии.

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

Content Branching позволяет рассматривать такие изменения как отдельную ветку контента.

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

Это уже выходит за рамки обычных drafts и versions. Ветка описывает не состояние одного документа, а набор связанных изменений.

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

Подробный разбор Content Branching мы сделаем отдельно после практического теста.

Payload продолжает развивать работу с ИИ

Ещё одно заметное направление Payload 4 — MCP и работа с ИИ-агентами.

Официальный MCP-плагин позволяет агенту получать структуру Payload, читать данные и выполнять разрешённые операции с коллекциями и глобальными сущностями. В четвёртой версии он переписан заново — «Rewritten MCP» прямо назван в списке изменений релиза.

В последних предварительных сборках четвёртой версии появилась ещё одна часть этой системы — LLM Instructions. Мы разбирали её на прошлой неделе: теперь проект может передавать агенту не только схему, но и правила работы с ней.

posts
 ├─ title
 ├─ slug
 ├─ content
 ├─ category
 └─ status

Например, вот такие:

Новые статьи всегда создавай как draft.
Не создавай новые категории без явного указания.
Не меняй slug опубликованных материалов.
Перед публикацией материал должен пройти редакторскую проверку.

Часть инструкций задаётся разработчиком в конфигурации, часть можно поддерживать непосредственно из административной панели.

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

Для проектов, где ИИ уже участвует в наполнении или администрировании CMS, это намного полезнее ещё одного отдельного «AI-поля».

Файлы теперь тоже получают версии

В Payload давно есть Versions для документов. Можно хранить историю изменений, сравнивать состояния документа и восстанавливать предыдущие версии.

В Payload 4 этот механизм распространяется и на загружаемые файлы: «File upload versions» входят в список изменений релиза.

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

Например, редактор заменил PDF с документацией новой редакцией или загрузил обновлённый вариант изображения. Возможность хранить историю таких изменений позволяет работать с файлами примерно так же, как с остальными документами Payload.

Параллельно перерабатывается сама система загрузок и обработки изображений. В четвёртой версии появляются новые API трансформации файлов и механизм variants.

Payload выходит за пределы Next.js

Payload последних лет очень тесно связан с Next.js. В четвёртой версии разработчики начинают расширять количество вариантов его использования.

Одно из главных направлений — TanStack. Интеграция с экосистемой TanStack заявлена в списке изменений релиза наряду с новой админкой и Content Branching: Payload можно будет использовать в архитектурах, которые не завязаны исключительно на Next.js.

Это важное изменение именно для Payload как фреймворка.

Payload давно уже можно использовать не только как классическую CMS. Коллекции, Access Control, Local API, хуки, Jobs, собственные endpoints и плагины позволяют строить на нём полноценную серверную часть приложения.

Поддержка других вариантов окружения делает эту модель менее зависимой от одного веб-фреймворка.

Пока это направление ещё развивается, поэтому окончательные выводы разумнее делать после стабилизации четвёртой версии.

Изменилось много вещей под капотом

Кроме крупных пользовательских функций, Payload 4 содержит довольно большой объём архитектурных изменений.

Меняется работа Local API, перерабатываются некоторые внутренние API административной панели, удаляются устаревшие интерфейсы, развивается система обработки файлов и меняется часть поведения коллекций. В релизе это названо «Foundational improvements», а для перехода с третьей версии выпущены кодмоды: npx @payloadcms/codemod@beta.

Это объясняет, почему четвёртая версия довольно долго проходила через canary-сборки.

Причём изменения уже заметны сторонним разработчикам. Авторы плагинов начали выпускать отдельные сборки под Payload 4 и находить места, где старые интеграции требуют адаптации.

Для экосистемы это, пожалуй, главный показатель приближения крупного релиза: четвёртая версия начинает существовать не только внутри основного репозитория Payload.

Это пока бета

4.0.0-beta.0 — важный рубеж, но не стабильный Payload 4.

Бета нужна для тестирования новой версии на реальных проектах, поиска регрессий и адаптации экосистемы. Для production-проектов пока остаётся актуальной стабильная третья ветка.

Есть и практическая деталь, которую легко пропустить: бета требует Node не ниже 24.15.0, тогда как третья ветка работает на Node 18 и 20. К моменту обновления придётся обновить и окружение.

Попробовать Payload 4 отдельно можно уже сейчас:

npx create-payload-app@beta

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

Остальным спешить пока некуда.

Что в итоге

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

Новая админка делает Payload более полноценным рабочим инструментом для редакций. Content Branching добавляет новый уровень работы с изменениями контента. Версии распространяются на файлы. MCP и LLM Instructions развивают сценарий, в котором с CMS работают ИИ-агенты. А поддержка TanStack постепенно уменьшает зависимость Payload от одной конкретной архитектуры приложения.

При этом 4.0.0-beta.0 всё ещё остаётся тестовой версией. Самое интересное сейчас — уже не список функций, а то, как они покажут себя на реальных проектах.

И первым из них мы отдельно разберём Content Branching.

Источники

https://github.com/payloadcms/payload/releases/tag/v4.0.0-beta.0

https://payloadcms.com/docs/beta/getting-started/what-is-payload

https://payloadcms.com/docs/beta/migration-guide/v4

https://www.npmjs.com/package/payload?activeTab=versions