By 2026, the headless CMS landscape has sorted itself into two camps: content-as-a-service platforms that manage content in their cloud (Contentful, Sanity, Storyblok), and self-hosted systems where data and runtime stay in-house. Payload is the most prominent representative of a third, younger idea: the CMS is no longer a separate system but part of the application itself – same repository, same deployment, same language. For decision-makers this is more than developer convenience: it changes cost structure, data sovereignty and the operating model.
What Payload does differently, technically
Three architectural decisions define Payload – and explain why it established itself so quickly in the Next.js ecosystem:
- Config as code: collections, fields, validation and access rules are defined as TypeScript configuration – not clicked together. The data model lives in the Git repository, goes through code review and CI/CD, and is reproducible across environments. For governance, that is a fundamental difference: every schema change is traceable, testable and revertible.
- Next.js-native since version 3: Payload installs into the Next.js application. Admin panel, APIs and website share one deployment; the Local API allows data access without HTTP round-trips directly in server rendering. In practice: one repository, one pipeline, one hosting – instead of CMS instance plus front end plus synchronisation.
- Your database instead of a content cloud: content lives in PostgreSQL (or MongoDB) on your infrastructure. Backups, encryption, retention and deletion policies follow your rules – not a content-SaaS contract.
Which products does Payload CMS replace?
Payload occupies the intersection of headless CMS, application backend and admin framework. Depending on your starting point, it substitutes different systems:
| System | Model | When Payload is the alternative |
|---|---|---|
| Strapi | open-source headless CMS (Node.js), open core | when you want TypeScript end-to-end, Next.js integration and features without enterprise gating |
| Directus | database-centric open-source CMS/backend | when the data model should live in code rather than a database UI |
| Contentful / content SaaS | content-as-a-service, usage/seat-based plans | when subscription costs, data sovereignty or API limits argue against the cloud |
| WordPress + ACF (headless) | PHP ecosystem with field plugins | when the PHP/plugin stack should give way to a typed TypeScript stack |
| Homegrown CMS/admin build | custom backend with admin UI | Payload replaces the custom build: admin, auth and CRUD are solved, your logic joins as hooks and endpoints |
| Firebase/BaaS for content apps | BaaS data storage without editorial UI | when content needs a real editorial interface with roles and approvals |
The last row is worth noting: because Payload ships authentication, roles and access control in its core, it often replaces not just the CMS but half the application backend – customer portals, member areas and internal tools grow on the same foundation as the content.
The advantages of a code-first open-source CMS
- No license and no content-SaaS costs: the MIT license knows no feature gating – localisation, versioning, auth and access control cost nothing extra. The cost curve tracks your infrastructure, not entries, API calls or editor seats.
- Data sovereignty as architecture: content, users and media live in your database on EU infrastructure. GDPR questions (storage location, processing, deletion) are answered by the architecture, not a contract annex.
- One stack, one deployment: CMS and application share TypeScript, repository and pipeline. Fewer interfaces, fewer deployments, fewer systems for a team to master.
- Extensibility without platform limits: hooks, custom endpoints, custom React components in the admin – business logic becomes part of the system instead of a workaround beside it.
- Exit security: standard PostgreSQL plus MIT code in your own repository – there is simply no vendor who could withdraw the service or dictate terms.
- Auth included: login, roles, API keys and field-level access rules are core features – for many projects a separate auth system becomes unnecessary (the boundary to full IAM below).
The Figma acquisition: what it means for decision-makers
In 2025, Figma acquired Payload – for an open-source project of this size a defining event, and one that rightly gets questioned in evaluations. The sober assessment: in the short term, the acquisition means commercial backing, a full-time team and growing visibility – Payload is better funded than most open-source CMS. In the medium term, strategic uncertainty remains about how strongly the roadmap will serve Figma use cases. The structural safeguard is the MIT license: the entire core including the admin panel is open, forkable, and keeps running on your infrastructure – on your terms, independent of product decisions in San Francisco. Treat the acquisition as what it is: a governance fact that belongs in the decision record – not a knockout criterion, but not a sales pitch without context either.
Payload vs. Sanity: the honest line, drawn from using both
We implement both systems – which is exactly why this comparison belongs here, without tribalism. The systems optimise for different priorities:
| Criterion | Payload | Sanity |
|---|---|---|
| Core model | code-first, self-hosted, part of the Next.js app | content lake as a service, Studio as the interface |
| Data storage | your PostgreSQL/MongoDB instance (EU, self-hosted) | Sanity cloud (content lake), governed by contract |
| Cost model | €0 license; cost = infrastructure + project | free tier; Teams from ~$15/user/month (as of July 2026) |
| Editorial collaboration | solid (versions, drafts, live preview) | best in class (real-time collaboration, presence, comments) |
| Structured multi-channel content | good (blocks, relations) | reference class (Portable Text, GROQ, releases) |
| Auth & access control | included in core, field-level | Studio roles; app auth is solved separately |
| Typical sweet spot | app-adjacent content, portals, data sovereignty, no SaaS subscription | editorially driven sites, large content teams, multi-channel |
Our rule of thumb from projects: if the endeavour is an application with content (portal, product, internal tools) or demands strict data sovereignty, the path leads to Payload. If it is an editorially driven content platform with many authors and channels, Sanity plays its strengths – as described on our Sanity service page. In between, the individual case decides.
The architecture in 90 seconds
Payload organises content in collections (pages, articles, products, users) and globals (singletons like navigation or settings). Fields range from primitives via relations to blocks – reusable content components for page-builder patterns. Hooks run logic on read and write operations (validation, enrichment, webhooks); access-control functions govern permissions per collection, document or field. Externally, three APIs speak: REST and GraphQL for external consumers, and the Local API for latency-free access inside your own Next.js server. The admin panel is React – customisable down to individual field components and views. Versioning, drafts, scheduled publishing, localisation and live preview are core features.
When Payload fits – and when it does not
Honest is honest, even for a system we like to use. Payload does not fit if no TypeScript competence is available and no partner carries operations – a code-first CMS without code competence forfeits its core advantage. It also does not fit when large editorial teams need real-time collaboration (then Sanity), or when all you need is a lean marketing site with minimal IT (then managed platforms are legitimate too). Payload plays to its strengths with customer portals and applications with editorial components, strict data-sovereignty requirements, Next.js teams reducing system boundaries – and wherever content-SaaS subscriptions or CMS license models stop making economic sense.
Operations and cost for decision-makers
The calculation follows the familiar open-source pattern: license zero, cost in project and operations. A focused Payload setup sits at €8,000–20,000 in our project classes, a full application with portal features at €20,000–60,000; EU operations (for us typically Hetzner with PostgreSQL) in the low three-digit monthly range. The structural difference to content SaaS: no cost per editor seat, entry or API call – and the database is yours from day one. Where Payload’s built-in auth ends and real IAM begins is covered in our Keycloak guide.
