Payload CMS overview
Discover how Payload CMS combines the power of headless content management with developer-focused features for project flexibility and control.

This article is part of a series focused on identifying the top Next.js CMS options, offering insights into the best headless CMS platforms for developers and content creators.
Payload has also made it into our list of best React headless CMS for its flexibility and integration features.
Payload is an open-source, fullstack Next.js framework that gives you a TypeScript backend, a REST and GraphQL API, and a fully customizable admin panel - all generated from a single config file in your codebase. It works as a headless CMS, an application framework, or both at once. In June 2025, Payload joined Figma. And this a move that signals where the platform is heading next.
It's a CMS built entirely in your codebase. There's no SaaS dashboard, no vendor sitting between you and your data, and no pricing page that gets uncomfortable when your traffic grows. You deploy it, you own it, and if you ever want to change something about how it works, including the admin UI itself, the code is right there.
How Payload Works
Payload installs directly into your existing Next.js /app folder. No separate backend service to maintain, no extra deployment to manage - your CMS and your frontend live in the same codebase.
Everything is defined in code. Collections, globals, fields, access control, hooks. All of it lives in payload.config.ts. From that single config, Payload generates a full REST and GraphQL API, a database schema, and an admin UI automatically.
import { buildConfig } from 'payload'
export default buildConfig({
admin: {
user: Users.slug,
livePreview: { ... },
components: { ... },
},
collections: [Users, Posts, Media],
globals: [Header, Footer],
db: mongooseAdapter({ ... }),
editor: lexicalEditor({ ... }),
localization: { ... },
plugins: [seoPlugin({ ... }), formBuilderPlugin({ ... })],
})
Editors work with the content. Developers own the structure. That separation is intentional and for most teams building something serious, it's exactly what you want.
Payload started MongoDB-first approach. PostgreSQL and SQLite came with v3. Today you pick your adapter and swap it out like any other config option. Runs on any Node.js infrastructure, with one-click deploy to Vercel if you want to move fast.
Payload and Figma
In June 2025, Payload was acquired by Figma. For teams evaluating Payload today, there are a few things worth understanding about what that means in practice.
Payload Cloud was discontinued for new projects shortly after the acquisition. Self-hosting is now the only path - and if you're starting a project today, that decision needs to be made upfront, not retrofitted later.
What didn't change: Payload remains MIT licensed and fully open-source. Figma confirmed this publicly. The codebase is yours, the data is yours, and the licensing terms haven't moved.
What's coming: Figma is building a design-to-deployment pipeline called Figma Sites, and Payload is the CMS layer behind it. For teams already in the Figma ecosystem, that integration will eventually close the gap between design and production content management. It's early, but the direction is clear.
Open Source and Self-Hosted
Most headless CMS platforms are SaaS. You get an API, a hosted admin, and a pricing tier that grows with your usage. That model works fine until it doesn't. A pricing change, a policy update, and your content infrastructure is someone else's decision to make.
Payload is MIT licensed and fully self-hosted. Your data lives in your database, on your infrastructure. No third party has access to it, no vendor can change the rules on you, and there's no monthly bill that scales with your content volume.
For a deeper look at how Payload compares to other self-hosted options, see our breakdown of the best self-hosted headless CMS platforms.
Self-Hosting in Practice
Self-hosting Payload comes down to three things: your Next.js hosting, file storage, and database. Each is a separate decision, and each has solid options depending on your project.
We continuously research modern stacks, looking for technologies that integrate cleanly, stay lean, and hold up in production. A few combinations that work well:
- Vercel + Vercel Blob + Neon - Neon is a serverless Postgres that works particularly well for SSG-heavy sites. DB calls happen mostly at build time and on revalidation, so costs stay low and predictable.
- Vercel + Supabase Storage + Supabase Postgres - a reliable choice for more dynamic projects where you want a single platform handling both storage and database.
- Cloudflare Workers + R2 + D1 - an edge-first option that Cloudflare documented on their blog. Works well when you want global distribution without managing servers and want everything within a single provider.
None of these stacks wins by default. The right one depends on your specific constraints. We help teams find that answer before they commit to the wrong infrastructure
Admin Panel Customization
Most CMS platforms give you an admin UI and a list of things you can configure. Payload gives you the source code. A better way to think about it: Payload is a framework for building your own CMS, not a product you configure around.
That doesn't mean you're starting from zero. The must-have features are already there: live preview, version control, asset management, localisation, drafts. The framework framing matters when you hit the edges of what those defaults cover, which on any serious project, you will.
Payload's admin is a React app - every part of it is yours to change.
The admin panel is a React app. You can override components, add custom views, and reshape the editorial experience to fit exactly how your team works.
For a closer look at what's possible, see our breakdown of Payload admin panel customization.
Plugin Ecosystem
Payload's code-first architecture makes it straightforward to extend. Collections, hooks, and field schemas are all just TypeScript. So writing a plugin that taps into them feels like writing any other part of your application, not fighting an abstraction layer. Working across multiple Payload projects, we've built up a set of plugins that solve problems we kept running into. A few worth highlighting:
- Translations plugin - AI-powered localisation inside the admin. Translates text and rich text across nested fields, supports bulk translation, two modes (overwrite or fill-empty-only), and draft-aware publishing. OpenAI included, custom providers supported.
- A/B testing plugin - automatically maintains a variant manifest keyed by path, designed to be read by Next.js middleware at the edge. Users get routed to the correct variant without an extra database round-trip.
- Block presets plugin - lets editors save and reapply reusable block configurations in the admin panel, which cuts down repetitive content work on large sites.
Payload ships with a solid set of official plugins covering the most common needs: SEO, forms, redirects, and search. On top of that, there's a growing number of community plugins - a direct consequence of an architecture that developers actually want to build on.
Lexical Editor
Payload ships with Lexical as its default rich text editor. The same editor handles a simple article body and a complex page builder. How far it goes depends on how you configure it.
The extension model is built around custom nodes: drop in any component the editor needs to support. Charts, CTAs, carousels, custom media blocks - they live inside the editor as first-class content.
Lexical rich text editor
Payload also ships official converters for Lexical output. HTML and plain text out of the box. For teams migrating from another platform, that cuts down the content transformation work at the point where migrations tend to get messy.
Enterprise
Payload has an enterprise tier. It's not managed hosting or a separate platform. The enterprise tier is a set of plugins. Things like audit logs, password protection, lexical AI features, and other capabilities that larger teams typically need. The open-source core stays the same.
Payload for eCommerce
Payload works as a content layer on top of your eCommerce engine for managing pages, editorial content, custom admin workflows, and anything that sits outside the product catalogue. It integrates with managed platforms like Shopify, open-source engines like Medusa, and others.
The Medusa combination is worth calling out. Both are MIT licensed, both are self-hosted. You own the product logic, the content, the data, and the infrastructure. No feature gates, no third-party platform deciding what you can and can't build. If a client's requirements outgrow what a managed platform allows, this stack doesn't have a ceiling.
For a broader look at headless eCommerce options that work well with Payload, see our Next.js headless eCommerce platforms comparison.
AI and MCP
Headless CMS platforms split into two camps: schema-in-code and schema-in-UI. Storyblok is a good example of schema-in-UI. Payload is schema-in-code, and in the current AI-assisted development environment, that distinction matters more than it used to. When your schema lives in code, AI tools can actually reason about it.
Payload now has an official MCP plugin, which means AI agents (Claude, Cursor, or any MCP-compatible client) can read, create, and update content in your CMS directly, without a custom integration layer.
In practice, your content team can prompt an AI assistant to draft a post, update a collection or query your data and it happens inside Payload, against your actual collections, access rules, and data structure.
And because the codebase is strongly typed with a schema that lives in code, AI tools can iterate on it directly - suggesting fields, generating queries, refining structure. You get a tighter feedback loop than a UI-defined schema can offer, which makes Payload a good fit for dev teams leaning into AI-assisted workflows.
Given that Payload is now part of Figma, AI is clearly part of where this platform is heading.
Migration to Payload
Teams migrate to Payload from traditional CMS platforms like WordPress, or SaaS headless options like Contentful. The reasons vary: a project that's outgrown its platform, costs that no longer make sense at scale, a need to own the infrastructure and data, or requirements around flexibility that a managed platform can't meet.
Payload's architecture maps legacy data structures directly into TypeScript schemas, which makes it a practical target for migrations rather than just a greenfield choice. Content moves from a restricted vendor environment into a codebase you fully own.
There are two examples of migration we've documented: transitioning from WordPress and an automated migration approach for Contentful.
When to Use Payload
Use Payload when:
- You need full control over your data and infrastructure
- Your project is built on Next.js
- You're building something custom that doesn't fit a standard CMS mold
- You're working in a regulated industry or have strict data privacy requirements
Skip it when:
- No developer available for the initial setup. The hosting and configuration is a one-time investment, but someone needs to get it there
- Editors need to manage schema changes themselves
- You need a turnkey solution with minimal configuration
For a broader comparison of where Payload sits against other open-source options, see our open-source CMS comparison for 2026.
Working with Payload
FocusReactive is an official Payload CMS partner. We've built and shipped projects on Payload across a range of use cases - from custom admin panels to complex content architectures that needed full data ownership.
If you'd like to migrate to Payload CMS or you are building it from scratch, get in touch. We are a headless CMS agency and we set up a free consultation with you to discuss your project and explore how Payload CMS or any other platform can serve your needs, ensuring you make the most of its powerful features.







