Payload CMS vs Strapi: which headless CMS is right for your project?

You’ve narrowed the shortlist to two open-source, self-hosted, TypeScript options, and you need to pick one for a real build. Payload is an application framework and backend with an admin panel, and it installs into a Next.js app. Our guide to Payload CMS covers how it works. Strapi is a Node.js headless CMS that runs as its own service, with an admin panel and a visual Content-Type Builder.

Payload fits a team that builds in TypeScript and Next.js and wants the content model, access rules and business logic written in code. Strapi fits when the database has to be MySQL or MariaDB, when you want to draft the content model in an admin UI, or when you want SSO at a published price. If you’re weighing more than these two, our overview of Payload CMS alternatives compares the wider field.

Every price and plan on this page was read from each vendor’s own pages as of September 2026.

• Payload CMS vs Strapi at a glance
• Where does each one run in your stack?
• Who changes the content model after launch?
• Which databases can you use?
• How do users, roles and permissions work?
• What’s free, and what do you pay for?
• How many plugins does each have, and how do upgrades land?
• Where Payload wins
• Where Strapi wins
• How to decide
• Payload CMS vs Strapi: common questions
• Final verdict

Payload CMS vs Strapi at a glance

Major versions come from GitHub’s REST API (the latest-release endpoint for payloadcms/payload and strapi/strapi), read on 24 September 2026.

Where does each one run in your stack?

Payload’s admin panel and API run as a Next.js app, and Strapi always runs as its own Node.js service. Either one can serve as many frontends as you need.

Payload’s installation guide lists Next.js as a requirement, and its admin panel is part of that Next.js app. When your public site lives in the same app, server code can read content through the Local API, which queries the database directly with no HTTP request. When the frontend is one or more separate apps, on another stack or on mobile, they call Payload’s REST or GraphQL API like any other client. Payload can also run outside Next.js for scripts and separate backend services, although the admin panel stays a Next.js app.

Strapi is a standalone Node.js server with its own admin panel, and every frontend talks to it over REST or GraphQL.

In practice, where each one runs changes how you deploy it, and either one serves a website, a mobile app and a partner feed from the same content. For example, a Nuxt marketing site and an iOS app can read the same articles over REST from Payload or from Strapi. What Payload adds is the option of a Next.js frontend in the same app, where a server component reads a signed-in user’s reports through the Local API with no API layer to secure in between.

Who changes the content model after launch?

On both platforms, a change to the content model on a live site is a code change that a developer deploys.

Strapi’s Content-Type Builder lets you create collection types, fields and components by clicking through the admin, and it writes the result into schema files in your project. For example, a new Invoice type becomes a schema.json file under ./src/api/invoice/content-types/invoice/, following the layout in Strapi’s models documentation. Strapi’s Content-Type Builder documentation marks it "Available in Development environment only". So the builder speeds up the first draft of a model on a developer’s machine, and the files it writes then go through version control and a deploy like any other code.

Payload skips the builder, and its comparison page on Strapi puts the case in one line, "If you’re going to write code, then write code." You define collections and fields in TypeScript config, Payload generates types from it, and on Postgres a model change comes with a database migration. For example, if a marketing lead wants a "campaign end date" field on a live site, a developer adds it on either platform.

Developers ask this on the r/PayloadCMS thread comparing the two, where one asks whether Strapi’s admin is still generating files you then have to manage. It is, and in production those files are the only way the model changes. Where the schema is enforced once a document is written is a separate question, covered in our Payload vs Sanity comparison. If you want a model that people edit in the admin at runtime, with no files at all, that’s the database-first approach in our Payload vs Directus comparison.

Which databases can you use?

Payload officially supports MongoDB, Postgres and SQLite, and Strapi supports PostgreSQL, MySQL, MariaDB and SQLite. If your organisation has already standardised on a database, that may settle the choice.

Payload connects through a database adapter, with MongoDB on Mongoose and Postgres and SQLite on Drizzle. Strapi’s database documentation lists PostgreSQL 14 or later (17 recommended), MySQL 8.0 or later (8.4 recommended), MariaDB 10.3 or later (11.4 recommended), and SQLite 3.

Strapi’s documentation also says it doesn’t support MongoDB or any NoSQL database, it doesn’t support cloud-native databases such as Amazon Aurora or Google Cloud SQL, and it isn’t meant to connect to a database that a Strapi application didn’t create.

For example, a team that runs everything on MySQL has one option here, and it’s Strapi. A team whose data already sits in MongoDB has the other.

How do users, roles and permissions work?

Payload writes access rules as functions in code, and Strapi sets them in the admin panel through two separate systems. Both can reach down to the field.

In Payload, every collection, global and field can have an access function for each operation, such as create, read, update and delete. A function can return true or false, or a query constraint that limits which documents the user can reach, as Payload’s access control documentation sets out. The admin panel reads the same rules, so a collection a role can’t edit is hidden from that role.

In Strapi, admin roles control what editors can do in the admin, per content type, per field and per action, with optional conditions, and role-based access control is free in every edition. The Users & Permissions feature manages end users, the people who call your API from a website or app, with JWT login and roles that allow or deny each API action.

For example, take a member portal where each customer may see only their own invoices. On Payload, that’s one read-access function on the invoices collection that returns a query, so each customer’s list only ever contains their own invoices. The pattern follows Payload’s collection access documentation:

import type { CollectionConfig } from 'payload'

export const Invoices: CollectionConfig = {
  slug: 'invoices',
  access: {
    // Logged-in customers see only invoices that point at them
    read: ({ req: { user } }) => {
      if (!user) return false
      return { customer: { equals: user.id } }
    },
  },
  fields: [
    { name: 'customer', type: 'relationship', relationTo: 'users', required: true },
    { name: 'total', type: 'number', required: true },
  ],
}

On Strapi, the end-user role grants access to the invoices API, and the ownership check is custom code. Strapi’s documentation recommends a route middleware for it, which it calls an is-owner middleware, and says "proper implementation largely depends on your project’s needs and custom code" (Strapi middlewares documentation). Our Payload multi-tenancy guide covers the next step up, where whole organisations share one install.

What’s free, and what do you pay for?

Both cores are free, and the two vendors put different features behind their paid plans.

Payload’s rows come from its docs on versions, drafts and scheduled publishing and live preview, its Enterprise page, and its MIT licence. Strapi’s come from its CMS pricing page and the plan labels in its docs for Content History, Releases, Review Workflows, Audit Logs and SSO. All were read on 24 September 2026.

If versions, scheduling and live preview are enough, Payload’s free core covers them and Strapi needs Growth. If you need SSO, Strapi lets you cost it from its pricing page today, while on Payload it comes with an Enterprise licence, priced on request. Approval workflows and audit logs are enterprise plans, priced on request, on both. For example, a team with ten editors that needs SSO can price Strapi Growth plus the SSO add-on from Strapi’s pricing page before speaking to anyone.

On hosting, Strapi Cloud runs from $35 per project a month on Starter to $90 on Pro and $450 on Business, and the Starter plan sleeps when idle. Payload Cloud has new projects currently paused, according to Payload’s notice on joining Figma, so you’d self-host a new Payload build today. What self-hosting Payload costs in practice is in our breakdown of what Payload CMS costs to run.

Both cores are MIT licensed, and Strapi’s paid Growth and Enterprise features sit under a separate commercial licence. How the licences in this category differ, including the one that isn’t MIT, is covered in our Payload and Directus licence comparison.

How many plugins does each have, and how do upgrades land?

Strapi has more plugins and a longer history. Its GitHub repository dates from September 2015 and had 73,223 stars on 24 September 2026, against 44,914 for Payload’s, which dates from January 2021, according to GitHub’s REST API that day.

Strapi’s Marketplace listed 348 packages on 24 September 2026, and Strapi’s comparison page describes browsing and installing plugins from inside the admin panel. Payload’s official plugins are packages you add to the config, such as SEO, search, redirects, form builder and multi-tenancy, and community plugins are found through the payload-plugin topic on GitHub. For example, if a maintained Strapi plugin already covers the integration you need, that’s integration code you don’t have to write.

Payload’s smaller catalogue matters less than the count suggests. Payload’s plugin documentation describes a plugin as a function that takes in an existing config and returns a modified one, with new fields, hooks, collections, admin views or custom endpoints. Because a plugin receives the whole config, it can reach any part of it, so building your own is ordinary TypeScript work, and Payload’s guide to building a plugin starts from a template.

Both have shipped a breaking major version in recent years, and both publish a migration guide for it, Strapi’s v4 to Strapi 5 guide and Payload’s 2.0 to 3.0 guide.

Where Payload wins

Payload is the stronger choice when the content model is part of the product you’re building, with one or more of these:

• One TypeScript codebase where content, users and business rules are defined together
• Typed data end to end, because the types come from the config you wrote
• Access rules in code, per document and per field, reviewed in pull requests
• MongoDB or Postgres as the database you already run
• A free core that already includes versions, drafts, scheduled publishing and live preview

For example, a booking product that stores venues, time slots, customers and payments can define each one as a collection with its own access rules, and the admin panel shows each role only what it may touch.

We’ve built on Payload since 2025. Before choosing it, we compared Strapi from its documentation, alongside Directus, Sanity and WordPress. The config-driven TypeScript decided it. We keep Payload’s official documentation inside our repositories, our own setup guides our AI agents, and a backend defined in code fits that way of working.

Where Strapi wins

Strapi is the stronger choice when your constraints are the database, how the model gets drafted, the plugins you need, or pricing you can read before a sales call. In the terms of Strapi’s own comparison page, that means:

• MySQL or MariaDB, which Payload doesn’t officially support
• A visual builder for drafting the content model in development, which suits teams where not everyone writes TypeScript
• A larger plugin marketplace, with install from inside the admin
• Published prices for SSO, releases and a managed cloud, so procurement can cost the build before a sales call

For example, a company whose IT team runs MySQL and requires SSO on every internal tool can run Strapi on the MySQL it already operates and cost SSO from Strapi’s pricing page.

How to decide

1. Who shapes the content model, and where? If developers define it in TypeScript and review it in pull requests, lean Payload. If you want to draft it by clicking through an admin UI in development, lean Strapi.
2. Is the database already fixed? MySQL or MariaDB means Strapi. MongoDB means Payload. With Postgres or SQLite, either works.
3. Do you need SSO at a published price, or a managed cloud from day one? If yes, Strapi. Approval workflows and audit logs mean an enterprise plan on either. If your access rules belong in code and you’ll self-host, Payload.

Final verdict

Choose Payload when you want the content model, access rules and logic written in TypeScript, with an admin and API that run as a Next.js app. Choose Strapi when you run MySQL or MariaDB, when you want to draft the model in an admin UI, or when you need SSO at a price you can read today.

We build on Payload, and as of September 2026 we manage 27 Payload codebases, all built on Next.js. We shape the content model and access rules before quoting, then give you a fixed price and time budget, and hand over code your team owns. If you’re choosing between the two for a build, tell us what needs to change and we’ll talk it through.

References

• Payload, installation and requirements
• Payload, using Payload outside Next.js
• Payload, database adapters
• Payload, access control
• Payload, collection access control
• Payload, generating types
• Payload, database migrations
• Payload, plugins
• Payload, building your own plugin
• Payload, versions
• Payload, drafts and scheduled publishing
• Payload, live preview
• Payload Enterprise
• Payload licence (MIT)
• Payload 2.0 to 3.0 migration guide
• Payload has joined Figma, Payload Cloud notice
• Payload as an alternative to Strapi, Payload’s comparison page
• Strapi vs Payload, Strapi’s comparison page
• Strapi CMS pricing
• Strapi Cloud pricing
• Strapi, Content-Type Builder
• Strapi, models
• Strapi, middlewares and the is-owner pattern
• Strapi, database configuration
• Strapi, role-based access control
• Strapi, Users & Permissions
• Strapi, Content History
• Strapi, Releases
• Strapi, Review Workflows
• Strapi, Audit Logs
• Strapi, Single Sign-On
• Strapi, upgrading from v4 to Strapi 5
• Strapi Marketplace
• r/PayloadCMS, Strapi vs. Payload CMS
• Payload CMS: a practical guide
• Payload CMS alternatives
• Payload CMS vs Sanity
• Payload CMS vs Directus
• Payload CMS vs WordPress
• Payload CMS multi-tenancy
• What Payload CMS costs to run

All links checked and active as of 24 September 2026.