What is PayloadCMS / Why now
Goals for this chapter
- Be able to articulate what PayloadCMS actually is, in the landscape of Headless CMSes
- Understand the meaning of the shifts in 3.x — Next.js co-location, Server Components support, Postgres going stable
- Position PayloadCMS against other CMSes (Strapi / Sanity / Contentful) with the context of the Figma acquisition (post-2024)
- Have an opinion on whether it is a good fit or not for your own project
Headless CMS in one paragraph
A "Headless CMS" is a CMS that provides a content admin UI and a storage layer (DB), but no presentation layer (frontend). In contrast to "monolithic" systems like WordPress that bundle a theme layer, DB, and admin UI into one product, a Headless CMS lets you pick any frontend you like — at the cost of having to implement that frontend yourself. The presentation layer (Next.js / Astro / iOS / Android, …) consumes content via APIs.
Where PayloadCMS sits
PayloadCMS is one Headless CMS, and the features below differentiate it from the others.
| Feature | What it means |
|---|---|
| OSS (MIT) | The full source is public and forkable. No SaaS lock-in |
| Self-hosted | You run it on your own infrastructure and your own DB (Vercel / Railway / Docker / a bare Node server, …) |
| Code-first config | A single TypeScript file, payload.config.ts, defines everything from content models to auth |
| Next.js native (3.x) | A CMS that installs directly inside a Next.js app (official wording: "the first CMS that installs directly into any Next.js app") |
| Three APIs | REST / GraphQL are generated from the config, and the Local API is initialized with getPayload() and called directly inside Node |
The official site even describes Payload as a "Next.js fullstack framework". The project deliberately reaches beyond "just a CMS" toward "a fullstack framework for building applications on Next.js."
What changed in 3.x
PayloadCMS released v3.0 stable on November 19, 2024, and the 3.x line has brought a series of shifts.
- Co-location with Next.js: v2.0 (2023-10-09) introduced Lexical, Postgres, and Live Preview, and v3.0 (2024-11-19) completed the Next.js-native architecture. From 3.x onward it installs straight into the Next.js
app/directory — both the Admin UI and the APIs run as Next.js routes - Server Components support: the 3.x Local API can be called directly from React Server Components (RSC) in Next.js via
getPayload(). There is no HTTP hop — data access happens inside the Node process - Postgres adapter goes stable: MongoDB used to be the default. In 3.x
@payloadcms/db-postgresis stable, with Drizzle ORM-based migrations - SQLite / Vercel Postgres adapter: also based on Drizzle
- Lexical Rich Text editor stable: the older Slate-based editor has been replaced by Lexical (built by Meta), with inline/block components as a first-class feature
- Slimmer dependency footprint: down to 27 dependencies from 88 in v2.0 (ESM, React Compiler shipped early)
The direction here is clear: dissolve the Headless CMS seamlessly into the Next.js project. For teams already centered on Next.js, this changes how the system is operated.
The Figma acquisition
The official documentation prominently displays "Payload is now part of Figma!". As Figma absorbs developer-facing tools around design and content, PayloadCMS has been folded in — and the OSS / MIT license and roadmap have so far continued unchanged.
An observable consequence is the build-up of enterprise features (SSO / AI auto-embedding / publishing workflow). The OSS core stays open, while the enterprise layer grows. (We have not verified a formal announcement on whether the post-acquisition roadmap changed significantly.)
Comparing the main Headless CMSes
| CMS | Hosting | Config style | DB | Frontend integration |
|---|---|---|---|---|
| PayloadCMS | Self-host (OSS) | TypeScript file | Postgres / Mongo / SQLite | Co-located with Next.js |
| Strapi | Self-host (OSS) | Admin UI + JSON / JS | Postgres / SQLite / MySQL (NoSQL dropped in v5) | Via API (any frontend) |
| Sanity | SaaS | Studio + GROQ queries | Sanity-proprietary (realtime Content Lake) | Via API (any frontend) |
| Contentful | SaaS | Admin UI | Contentful-proprietary | Via API (any frontend) |
| Directus | Self-host (source-available) | Admin UI + JSON | Various RDB (SQL) | Via API (any frontend) |
What makes PayloadCMS distinctive is the combination "OSS / self-host" × "TypeScript config" × "Next.js co-location". It appeals to teams that want to avoid SaaS lock-in like Sanity or Contentful, while preferring to define models in code rather than in Strapi-style admin UIs.
Directus moved to the BSL (Business Source License) in 2024, and again to the MSCL (Monospace Sustainable Core License) with v12 in May 2026. Organizations under $5M in revenue and 50 employees can still use it for free, but it is no longer pure OSS (Directus blog: Evolving Our License).
When it fits — and when it doesn't
Typical cases where PayloadCMS fits well:
- You're building public sites or SaaS apps on Next.js (App Router) and want to own the content layer
- You need to keep data on your own DB / your own cloud (legal / compliance constraints, or to avoid SaaS billing)
- You want a type-safe content model defined in TypeScript
- You want auth, authorization, and media uploads from a single system (no separate Auth0 / S3 stack)
Cases where you should think twice:
- Non-engineers need to change the content model themselves — model changes are edits to
payload.config.tsplus a deploy - You only want to host on Edge runtime / static export — PayloadCMS requires a Node runtime
- You want a central content store that distributes the same content across many projects via a CDN — SaaS vendors have the edge here
- You just want to ship the fastest — initial setup with Contentful / Sanity is quicker
Wrap-up
- PayloadCMS = a Headless CMS that is OSS / self-hosted / TypeScript-configured / Next.js native
- 3.0 stable in November 2024 is the inflection point — co-location with Next.js, Server Components support, Postgres / SQLite adapters, Lexical stable
- The Figma acquisition has not touched the OSS core; it thickens the enterprise layer
- It's the first choice for teams who want to "co-locate a CMS with Next.js on my own DB." It is a poor fit when you need Edge-only / static-only hosting, or when non-engineers must change the model themselves
Next
In the next chapter, 02 Core Concepts — Config-First / Collections / Globals, we look at payload.config.ts and the Collections / Globals at the heart of PayloadCMS.