You’ve read the feature lists and the five-star ratings, and now you want to know what Payload is like to live with. That’s the question a developer asked on the Payload subreddit in January 2026, looking for “the ‘ugly truth’ behind the marketing” from teams running it for a year or more.
Version 3.90.2 shipped on 23 September 2026, and version 4.0 is in early testing, so a review written in 2024 or early 2025 describes a different product. As of October 2026, we manage 28 Payload codebases, all built on Next.js. We build on Payload, so we’re not neutral. This page covers what Payload does well, the trade-offs it asks you to accept, what goes wrong when it isn’t set up for production, and how secure it is.
- The verdict in short
- What Payload is in 2026
- What Payload does well
- The trade-offs you accept with Payload
- What goes wrong when Payload isn’t set up for production
- How secure is Payload?
- Payload scorecard
- Who should pick Payload, and who shouldn’t
- Payload CMS review: common questions
- What to do next
The verdict in short
Payload is a good choice when your content sits next to application logic and a developer will keep looking after it. It’s a TypeScript backend with a generated admin panel, and it’s at its best when the content model is part of the product. It’s a weaker fit when editors expect a visual page builder or live co-editing on day one, because a page builder takes development work and Payload doesn’t offer live co-editing yet. It’s the wrong choice when nobody will maintain the project after launch.
What Payload is in 2026
Payload is an open-source TypeScript backend, used as a headless CMS, that runs inside a Next.js app. You define your data in a TypeScript config, and Payload gives you a database schema, an admin panel and REST, GraphQL and Local APIs from it. It’s MIT-licensed, so you can use and host it for free.
Four things have changed since the reviews that still show up in search:
- It runs inside Next.js. Since version 3.0, the admin panel and your front end live in the same app and deploy together.
- It supports Postgres, MongoDB and SQLite. Many of the reviews on Capterra date from 2023, when Payload supported only MongoDB, and the newest is from February 2025.
- It’s part of Figma. Payload and Figma announced on 17 June 2025 that Payload had joined Figma, and our article on what the Figma deal means for Payload covers the details.
- Payload Cloud isn’t taking new projects. Payload’s notice says “deployment of new projects is currently paused”, while existing Cloud projects keep running, so new projects host themselves.
Version 4.0 is next. Payload’s 4.0 announcement of 9 June 2026 lists a redesigned admin panel, hierarchies, better asset management, improved MCP support and an adapter for TanStack Start, so Payload can run outside Next.js. As of 7 October 2026, 4.0 is still in canary releases, the latest being 4.0.0-canary.37 on 24 September.
What Payload does well
Each of Payload’s strengths comes from keeping your content model in code, because the admin, the API and the access rules are all built from it.
Your schema lives in your code
Every collection, field and access rule is a TypeScript object in your repository. Payload generates the types, so your front end knows the exact shape of every document, and a schema change goes through code review like any other change. For example, rename a field from summary to excerpt, and the TypeScript build flags every component still reading summary. The change then ships with a migration, so the database follows the code.
A schema in code also suits AI-powered development. A coding agent can read the config and see every field name, which is why we use Payload with AI agents through its MCP plugin.
The admin panel is generated, then yours to shape
Payload builds a working admin panel from your config, with lists, forms, drafts, versions and live preview. You can then replace any part of it with your own React components. For example, our clients run custom dashboards inside the Payload admin, from mini CRMs to logistics trackers, some with AI worked into the process. Our guide to what you can build with Payload shows more of these.
Access control is a function
Access rules in Payload are functions that return true, false or a query. That makes role-based access control (RBAC) plain code. You give each user a role, and every rule checks it, so “editors can publish, authors can edit only the posts they created” works at the collection, document or field level, and you test it like any other code. The same mechanism powers Payload’s multi-tenant plugin, which our guide to running several sites from one Payload walks through.
The Local API skips the network
Because Payload runs inside your Next.js app, server code can query the database through the Local API without an HTTP request. For example, a product page can load its product, its related products and its reviews in one server render, with no API layer in between.
No seat or API-call billing
Payload doesn’t charge per editor, per API call or per record. You pay for the server, the database and file storage, and you choose all three. Our Payload pricing guide breaks down what that usually costs.
The trade-offs you accept with Payload
Payload asks a few things of you by design. None of them is a defect, but each one should be a choice you make before the build starts.
You run it. Payload is self-hosted, so someone owns the server, the database, backups, scheduled jobs and updates. Our guide to where to host Payload covers the options.
Editors start with a plain admin. Out of the box, there’s no drag-and-drop page builder, and approval chains are custom work. Live co-editing isn’t available yet. Payload locks a document to one editor at a time by default, and its Enterprise page lists multi-player editing as still to come. Lucky Media’s review scores the editing interface 2 out of 5 for non-technical editors. The other side is that every part of the admin is a React component a developer can replace, so editors can get exactly the screens their work needs, such as the custom dashboards our clients run. It’s work to plan for at the start of the build.
There are fewer plugins. As of October 2026, Payload’s repository carries 12 official plugins, including SEO, search, a form builder, multi-tenant, redirects and ecommerce, and the rest you write.
It moves fast, and it expects TypeScript. Payload shipped 21 minor versions, from 3.70 to 3.90, between January and September 2026, and the 4.0 announcement says the redesigned admin removes Sass, so custom admin styles will need checking at that upgrade. Updates are routine work, and schema changes go through Payload migrations. Developers also need to be comfortable with TypeScript and Next.js. Community reports flag rough edges too. For example, one developer in the same Reddit thread finds that Local API results type a relationship as an ID, a document or null, depending on depth, so the code has to check which.
Across our builds, we haven’t hit a downside we’d hold against Payload itself. The known downsides come when production setup isn’t done correctly.
What goes wrong when Payload isn’t set up for production
Payload’s own performance, abuse prevention and deployment docs describe the settings that keep a project fast and safe in production. Skip them, and these are the six problems you’ll notice:
- Pages slow down as content grows
- Lists and searches crawl on big collections
- GraphQL queries load the server
- Saving a document or opening the admin feels slow
- The site launches with open doors
- Uploaded files disappear
Pages slow down as content grows
Payload populates related documents to a depth of 2 by default. On a page with many relationships, that can pull in far more data than you render. For example, at depth 2 a blog post loads its related posts, and then each related post’s author and categories as well. Payload’s depth docs say depth “can impact the performance of your queries by affecting the load on the database and the size of the response”.
The fix is to ask for less. Set depth as low as the page allows, and use select to return only the fields you render, which shrinks the response. The performance docs add one more rule, to host the database in the same region as your server.
Lists and searches crawl on big collections
This is the answer to the Reddit question about whether the admin holds up at 20,000 records. Payload indexes only id, createdAt and updatedAt by default, so a list filtered or sorted by any other field makes the database scan every document.
The fix is to set index: true on the fields you filter and sort by, as the indexes docs show. For example, an orders list filtered by status and sorted by delivery date needs both fields indexed, or one compound index on the pair, which Payload also supports.
GraphQL queries load the server
In GraphQL, the depth setting does nothing. The depth docs say “depth is based on the shape of your queries”, so a deeply nested query can ask for a great deal. Payload already handles the classic N+1 problem, where each related document triggers its own query. Its source code batches related lookups into one query per collection for every request, using the dataloader pattern.
What’s left is the size of the query itself. The abuse prevention docs say to set maxComplexity in the GraphQL config, where each field counts 1 and each relationship or upload field counts 10. They also recommend keeping maxDepth “as small as possible without interrupting dev experience” (it defaults to 10). If your front end doesn’t use GraphQL, you can turn it off with graphQL.disable: true.
Saving a document or opening the admin feels slow
Hooks, access functions and validations run on every request, so a slow one slows everything it touches. The performance docs ask for lightweight hooks, validations that only run when they need to, and long tasks moved out of the request. For example, a hook that sends a newly published post to a translation service is better as a job than as code the editor waits on.
The same docs cover the admin side. Custom admin components should avoid unnecessary re-renders, and a block used in many places should be defined once as a block reference, so the admin isn’t sent the same config again and again.
The site launches with open doors
Payload’s deployment checklist starts with security, and each item is a setting someone has to change:
- A
PAYLOAD_SECRETthat is “impossible to guess”, in the docs’ words - Access control checked for every collection that the public can reach
- Secure cookies on an SSL connection
maxLoginAttemptsandlockTimeon collections with logins- CORS and CSRF set to your own domains
- Create, read and update access restricted on upload collections
The docs also note that Payload doesn’t run uploaded files on the server, but they recommend scanning uploads if the public can submit them.
Uploaded files disappear
On hosts with an ephemeral filesystem, files saved to disk vanish on the next restart or deploy. The deployment docs name Heroku and DigitalOcean Apps as examples. The fix is a storage adapter that sends uploads to object storage such as Amazon S3 or Cloudflare R2.
| What you notice | What causes it | What prevents it |
|---|---|---|
| Slow pages, large responses | Default depth on relationship-heavy pages | Lower depth, use select, keep the database in the server’s region |
| Slow lists on big collections | Unindexed fields in filters and sorts | index: true, compound indexes |
| GraphQL load spikes | Large nested queries | maxComplexity, a low maxDepth, or GraphQL disabled |
| Slow saves and a slow admin | Heavy hooks, validations and components | Light hooks, jobs for long work, block references |
| Security gaps at launch | Default or skipped settings | The deployment and abuse checklists |
| Missing uploads | Ephemeral filesystem | A storage adapter |
How secure is Payload?
Payload’s security depends on two things, your configuration and Payload’s own code. The launch checklist in the production section covers your configuration. For the code, Payload publishes fixes through GitHub security advisories.
Between 1 September and 6 October 2026, Payload published 32 advisories, 6 rated critical, 18 high and 8 medium. They cover the core, the database adapters and several official plugins, and include SQL injection in the Postgres and SQLite adapters, remote code execution in the Form Builder plugin and authorisation bypasses in the multi-tenant plugin. All 32 were fixed by version 3.90.0.
For you, that means three habits:
- Stay on the latest stable release, and treat a security release as urgent.
- Watch the repository’s security advisories, so you hear about fixes when they ship.
- Treat the plugins you install as part of your attack surface, and update them with the core.
Payload scorecard
| Area | Verdict | Why |
|---|---|---|
| Content modelling | Strong | Collections, fields, blocks and relationships in typed code |
| Developer experience | Strong | Generated types, the Local API, one app with Next.js |
| Editor experience | Fair | Clean and usable, but a page builder or approval flow is custom work |
| Live collaboration | Weak | One editor per document, with locking; Enterprise multi-player editing still to come |
| Hosting and operations | Fair | Runs almost anywhere Next.js runs, and you run it |
| Plugins | Fair | Solid official plugins, few third-party ones |
| Running cost | Strong | Free software, no seat or API-call fees |
| Security upkeep | Fair | Public advisories with fixes, so updates are your job |
| Longevity | Strong | MIT licence, active releases, part of Figma |
Who should pick Payload, and who shouldn’t
Payload fits teams that want to own their backend and have a developer to look after it.
A website or online store. Payload works well here for teams of any size, from a single brand to an enterprise, as long as developers stay involved for changes and updates. If your team wants to install themes and plugins without a developer, our Payload vs WordPress comparison shows where WordPress is the easier fit.
An application backend. This is where Payload is strongest. It can be the whole backend for a SaaS product, a customer portal, an internal tool or the API behind a mobile app, with users, roles, records and content in one typed backend and one set of access rules. If you’d rather have a team shape and build it, that’s the work of our Payload CMS development service.
A site with no developer after launch. A hosted platform, where the vendor runs the backend, will serve you better. Our Payload vs Sanity comparison covers the best-known hosted option, and our Payload vs Strapi comparison covers the other popular self-hosted, open-source choice. For the full list, see our guide to Payload CMS alternatives.