Payload CMS: The Complete Guide (2026)
React
August 20, 2026•4 min read
I hope you enjoy reading this post. If you want us to do your frontend development or design, click here.
Author: Alex Vasylenko | Founder of The Frontend Company
Payload is an open-source, TypeScript-first headless CMS that installs directly into a Next.js application. The admin panel, the content APIs, and your frontend live in one codebase and ship as one deploy. You define the schema in code; Payload generates the database structure, a React admin UI, and REST plus GraphQL APIs from that config - and because it runs on your own infrastructure under an MIT license, there are no per-seat fees and no vendor sitting between you and your content.
This guide covers how Payload works under the hood, what it actually costs to run, how it compares to Strapi and Contentful, a realistic quick-start path, and an honest verdict on where it fits - and where it doesn't. We build and migrate CMS stacks for clients across the whole headless lineup, so the opinions here are the ones we give on calls.
What is Payload CMS?
Payload started as a developer-first answer to config-through-clicking CMSs: instead of assembling content types in an admin GUI, you describe collections, fields, and access rules in TypeScript, and everything else - database schema, admin panel, APIs, types - is generated from that single config. Version 3, released as stable in November 2024, took the idea further and made Payload install natively inside a Next.js app, a setup no other major CMS offered at the time.
Two facts frame where the project stands in 2026:
- It's backed by Figma. Figma acquired Payload in June 2025; the project stayed MIT-licensed and open source, and the team kept shipping under the new ownership - the repository sees active development daily.
- The community is large and active. The main repository sits at 44,000+ GitHub stars, with official plugins, templates, and an active Discord around it.
How does Payload's architecture work?
The core idea: Payload is not a separate service your frontend talks to over HTTP. It's a set of packages you add to a Next.js project. The admin panel mounts at a route (usually /admin), the APIs mount under /api, and your server components query content directly.
Four pieces matter:
- Config as code. payload.config.ts defines collections (structured documents), globals (singletons like navigation or settings), fields, hooks, and access control. The config is the source of truth - version-controlled, reviewable in pull requests, reproducible across environments.
- The Local API. Inside the same Next.js app, server components and route handlers call Payload's Local API - direct database access through Payload's data layer, no HTTP round-trip, no serialization tax. This is the biggest practical difference from any external headless CMS: fetching content in a server component is a typed function call.
- REST and GraphQL for everyone else. Payload still auto-generates REST and GraphQL APIs from the same config, so mobile apps, other services, or a separate frontend can consume content the classic headless way.
- Database adapters. Postgres and SQLite run through Drizzle; MongoDB runs through Mongoose. You pick the adapter in config, and Payload manages migrations for the relational options.
The one-codebase model has a concrete operational payoff: one repository, one CI pipeline, one deploy target. When the site and the CMS are the same Next.js app on the same infrastructure, the “CMS is down but the site is up” class of incidents mostly disappears - and so does the second hosting bill.
Which Payload features matter in production?
The feature list is long; these are the ones that decide real projects:
- Field- and document-level access control. Access rules are functions, not role checkboxes. “Editors can update posts, but only their own, and only in draft” is a few lines of TypeScript - the level of granularity multi-tenant and B2B products actually need.
- Auth built in. Payload ships authentication, including API keys, usable both for admin users and for your application's own users - one less service to integrate.
- Versions, drafts, autosave, and live preview. Editors get draft/publish workflows and a live preview of the real Next.js frontend, not an approximation of it.
- Localization at the field level. Mark fields as localized and Payload stores per-locale values; combined with access control, that supports per-market editorial teams.
- Hooks and a jobs queue. Lifecycle hooks plus a built-in task queue cover the “when content changes, do X” automation without bolting on a separate workflow engine.
- Lexical rich text. The editor is built on Meta's Lexical framework and stores structured JSON, not HTML - which keeps rendering, validation, and migrations tractable.
- Plugins. Official plugins cover SEO, form building, nested docs, search, redirects, multi-tenancy, and e-commerce, plus Stripe, Sentry, and import/export.
What does Payload cost to run?
Payload's core is MIT-licensed: free software, self-hosted, unlimited admin users, unlimited API calls. The real cost model is infrastructure plus your team's time.
- Hosting. A Payload + Next.js app deploys anywhere Next.js does - Vercel, a container on AWS or GCP, a plain VPS. Add a managed Postgres or MongoDB and S3-compatible storage for media.
- Managed option - currently in transition. Payload Cloud has paused deployments of new projects following the Figma acquisition; existing Cloud projects keep running while the team builds what comes next. For a new build today, plan around self-hosting.
- What you don't pay: per-seat editor fees, API overage tiers, or per-locale charges - the line items that make SaaS CMS invoices grow with your success.
The honest flip side: self-hosting means backups, upgrades, monitoring, and scaling are your responsibility. For teams with nobody to own that, a managed SaaS CMS can genuinely be the cheaper option once you price in attention.
Transform your UI for peak performance!
🔹
Unlock seamless, high-performance frontend solutions tailored to your business.
🔹
Get an interface that outshines competitors and delights your users.
Payload vs Strapi
The most common head-to-head, because both are open-source, self-hosted, and JavaScript-based. They differ in almost every architectural decision:
Dimension | Payload | Strapi |
|---|---|---|
Runtime model | Installs inside your Next.js app - one codebase, one deploy | Standalone Node.js service - separate app and deploy from your frontend |
Schema definition | Code-first: TypeScript config, version-controlled | GUI-first: Content-Type Builder in the admin |
Databases | Postgres, SQLite (Drizzle), MongoDB (Mongoose) | Postgres, MySQL, SQLite - no MongoDB since v4 |
Admin customization | Bring your own React components at field and view level | Theming and extensions within Strapi's design system |
APIs | REST + GraphQL, plus the in-process Local API | REST + GraphQL |
License and hosting | MIT; self-hosted (Payload Cloud paused for new projects) | Open core (MIT plus paid features); self-host or Strapi Cloud |
The verdict we give clients: pick Strapi when a non-developer needs to model content through a GUI, when the stack isn't Next.js, or when your team already runs it happily. Pick Payload when the frontend is Next.js, the team is comfortable in TypeScript, and you want schema changes to go through code review like everything else. The deciding factor is usually who owns the content model - developers point to Payload, mixed teams make it a genuine coin-toss worth a conversation.
Payload vs Contentful: the ownership question
Contentful is the opposite architectural bet: a fully managed enterprise SaaS with REST and GraphQL delivery APIs, an app marketplace, and strong localization - and no servers for you to run. The trade is control for convenience.
- Pricing model. Contentful's paid plans start at $300/month for the Lite tier, with custom enterprise pricing above it; costs scale with seats, spaces, and usage. Payload's software costs $0, and your infrastructure bill scales with traffic instead.
- Operations. Contentful runs the platform, owns uptime, and handles scale. With Payload, that responsibility is yours.
- Editorial platform. Contentful's roles, workflows, and marketplace apps are built for large content organizations with many editors and locales.
We build on both, and the fit question is honest in both directions: a forty-editor, multi-brand content operation has different needs than a product team where two developers and a founder touch content. If you're weighing the whole field for a Next.js project, we keep the full comparison in our guide to the best CMS for Next.js.
An honest Payload review: strengths and trade-offs
After building on it, here's the scorecard we actually give clients.
Where Payload is genuinely strong:
- Developer experience. One repo, generated TypeScript types end-to-end, schema in code, local development that behaves like production.
- Total cost of ownership for content-heavy products. No per-seat math, no API tiers - costs stay boring and predictable.
- Access control depth. Function-based rules make multi-tenant and B2B permission models first-class instead of a plugin fight.
- Ownership. Your data, your infrastructure, MIT license - procurement and compliance conversations get shorter.
Where it will push back:
- You run it. Backups, monitoring, upgrades, incident response - someone on your side owns uptime.
- Admin customization needs React developers. The panel is deeply customizable if you write React; it is not a no-code tool.
- Next.js-shaped. Payload 3 is built for Next.js. Other frontends can consume its REST and GraphQL APIs, but then you're skipping the Local API - the best part.
- A younger ecosystem. Fewer off-the-shelf plugins, themes, and specialist agencies than WordPress or even Strapi; expect to build more yourself.
- Developer-gated modeling. If non-technical stakeholders must create content types themselves, a GUI-first CMS fits better.
How do you get started with Payload? (a quick tutorial)
The fastest path from zero to a working admin panel, if you want to feel the DX before committing:
- Scaffold. Run npx create-payload-app in a terminal, pick a template (the website template is the fullest reference), and choose a database adapter.
- Define a collection. In payload.config.ts, add a collection - say, posts with title, slug, hero image, and rich text - and restart the dev server. The admin UI, database structure, and APIs for it now exist.
- Open /admin. Create the first admin user, add a document, save a draft, publish it.
- Query it in the frontend. In a server component, call the Local API - getPayload, then payload.find on the collection - and render the result. No fetch, no API keys, full types.
- Deploy. Push to Vercel or a container host, point the adapter at a managed Postgres or MongoDB Atlas, add S3-compatible media storage, set the secrets.
That's a real content backend in an afternoon. The work after that - modeling, access control, preview, migrations - is where the actual project lives, and where the official docs are unusually good.
When is Payload the right choice?
Our rule of thumb after shipping CMS projects across the whole lineup:
Payload is a strong pick when the frontend is (or is becoming) Next.js, the team writes TypeScript, content and code should live in one repository, and per-seat SaaS pricing or data ownership is a real constraint.
It's usually not the pick when nobody can own hosting, when editors need to design content types themselves, when you need mature enterprise editorial workflows out of the box - or when the stack isn't React at all. In those cases Sanity, Contentful, Storyblok, or Strapi can each be the better call, and we'll say so: platform choice is case-by-case, not a default. The full field-by-field comparison lives in our guide to the best CMS for Next.js.
If the decision is part of a commerce stack, our headless commerce team has opinions on where the catalog should live, too. And if the evaluation has already landed on Payload, that's exactly what our Payload CMS development services exist for - builds, migrations, and admin customization by people who write React daily.
Evaluating Payload for your product?
We build and migrate on Payload, Sanity, Contentful, Storyblok, and Strapi - and we'll tell you honestly which one fits your team, your editors, and your roadmap. Book a call and bring your requirements.
FAQ
Alex Vasylenko is the founder of The Frontend Company, DBC and several other successful startups. A dynamic tech entrepreneur, he began his career as a frontend developer at Deloitte and Scandinavia's largest banking company. In 2023, Alex was honored as one of 'Top 10 Emerging Entrepreneurs' by USA Today.
Follow the expert:
LEARN MORE
