By Mehdi HassanPayload and Strapi are the two open-source headless CMSs most teams shortlist when they want to self-host and keep their content in their own database. We run Payload in production on our own site, so we'll say plainly where that experience shapes our view, and where Strapi is the better tool. For the wider picture of editing models, blocks and roles, start with our hub on CMS setup for marketing websites.
Payload vs Strapi: what's the core difference?
The core difference in Payload vs Strapi is architecture. Payload 3 is a Next.js-native CMS: you install it into your Next.js app, and the admin panel and APIs run as routes in the same deployment. Strapi is a standalone Node.js application with its own admin and API, deployed separately from whatever front end consumes it.
Everything else follows from that. With Payload, your pages can read content through the Local API, a direct call in the server process with no HTTP round trip and shared TypeScript types. With Strapi, your Next.js site fetches content over REST or GraphQL like any other headless CMS, which also means a mobile app or a second site can use the same API just as easily.
Payload | Strapi | |
|---|---|---|
Where it runs | Inside your Next.js app | Its own Node.js server |
How the site reads content | Local API, REST or GraphQL | REST, or GraphQL via plugin |
Content model | TypeScript config in code | Built in the admin or as JSON schema files |
Databases | Postgres, MongoDB, SQLite | Postgres, MySQL, MariaDB, SQLite |
Managed hosting | Self-hosted with your app; check Payload Cloud's current status | Strapi Cloud or self-hosted |
Front ends it suits | Mainly Next.js | Any framework or app |
License | MIT open source | MIT Community Edition, paid tiers for extras |
How does each fit into a Next.js site?
Payload fits a Next.js site with less glue code, because it is part of the same app. Strapi fits with the standard headless pattern: a separate service, an API token, fetch calls and cache revalidation when content changes.
In a Payload project, a server component can query posts directly, and draft preview, auth and access control all share the app's session. There's one repository, one set of environment variables and one deploy. The trade-off is coupling: upgrading Next.js and Payload often happens together, and a CMS bug can affect the site build.
In a Strapi project, the CMS and the site evolve independently. You can redeploy the site without touching the CMS, scale them separately, and swap the front end later. The cost is a second thing to host and secure, plus the plumbing: webhooks to revalidate pages when editors publish, a preview route, and keeping API types in sync. Our explainer on what a headless CMS is covers this model in plain terms.
What is running Payload in production like for us?
Our own site, designify.design, runs Payload CMS 3 inside a Next.js 16 app on Cloudflare Workers, with Cloudflare D1 as the database and R2 for media. The blog you're reading is stored in it. That's first-hand experience of Payload on one specific stack, not a benchmark, and we haven't run Strapi in production at the same depth.
What we value most is that the content model, the admin and the pages live in one TypeScript codebase. A new field shows up in the admin, in the types and in the page code in the same pull request. What took real work was the hosting: Workers isn't Payload's default target, so builds, image handling and media storage needed extra setup. We wrote those lessons up in setting up Payload CMS for a marketing site.
Pros
- Site, admin and API ship as one app
- Content model is typed code, reviewed in pull requests
- Local API reads content without a network hop
- Access control, drafts and versions built into the core
Cons
- You own hosting, backups and database migrations
- Next.js and Payload upgrades are coupled
- Non-default hosts need extra configuration
- Less useful if your front end isn't Next.js
When is Strapi the better choice?
Strapi is the better choice when several front ends share one content API, when your site isn't built on Next.js, or when you want a managed host for the CMS without running it yourself. It's a mature open-source project with a large community, and it does the standalone headless job well.
- Many consumers. A website, a mobile app and an internal tool all reading the same content is exactly what a standalone API is for.
- Non-Next.js front ends. Payload's biggest advantage, living inside Next.js, disappears with Astro, Nuxt, SvelteKit or a native app.
- Visual content-type building. Strapi's Content-Type Builder lets a technical non-developer define fields in the admin during development, and it writes the schema files for you.
- MySQL or MariaDB shops. Strapi supports both; Payload's official adapters are Postgres, MongoDB and SQLite.
- Managed hosting. Strapi Cloud runs the CMS for you. Check Strapi's current plan page, since its tiers change.
One caution: Strapi's database docs say it doesn't support MongoDB or any NoSQL database, so a Mongo-based team would lean to Payload. And if you're coming from Strapi v4, the v5 upgrade changed the API's identifiers and response shape, which is worth budgeting for. Our headless CMS migration guide covers moves between the two.
How does the editing experience compare?
Both give editors a clean admin with drafts, roles, localization and media libraries, and both generate the editing forms from your content model. The real difference for editors comes from how well the developer models pages, blocks and previews, not from the brand.
Payload's admin is a React app generated from your collections and globals, with versions, live preview and field-level access built into the open-source core. Strapi's admin is also React, with the Content-Type Builder, Draft and Publish, and internationalization in its free edition. Strapi places some editorial features, such as content history, releases, review workflows and SSO, in its paid Growth and Enterprise tiers, so check its pricing page against your editorial needs before you commit.
Preview deserves its own check. In Payload, live preview runs inside the same app, so it's mostly configuration. With Strapi, the preview has to reach your separately hosted front end. Our guide to live preview and visual editing explains both setups.
What does each cost to run?
Neither charges a license fee for its open-source core, so the real costs are hosting, database, file storage and developer time. Payload usually means one deployment to pay for; Strapi usually means two, the CMS server and the site, unless you use Strapi Cloud.
With Payload, the CMS shares the site's hosting, so for a marketing site the extra cost is mostly the database and media storage. With self-hosted Strapi, you run a Node server that stays up for the admin and API, plus its database and storage provider. Strapi Cloud swaps that ops work for a monthly plan, and Strapi's paid CMS tiers add features on top. Prices change, so check both vendors' current pages rather than relying on figures from any blog post, including ours.
Hypothetical example: a 12-page SaaS site with a blog
For example, suppose a SaaS startup wants a 12-page marketing site, a blog and case studies, with two marketers editing and the product app on a separate stack.
On Payload, we'd build pages from blocks, the blog and case studies as collections, and pricing and navigation as globals, all inside the Next.js site, with one host and one database.
Now suppose the same company also wants its mobile app to show the case studies and changelog. That tips the balance toward Strapi, or toward exposing Payload's REST API to the app, because content now has more than one consumer.
Which open-source headless CMS should you pick for a Next.js marketing site?
For a single Next.js marketing site with a developer or studio who owns it, pick Payload. For a content API that serves several apps or a non-Next.js front end, pick Strapi. Both are sound open-source projects with active development, so you're choosing a shape, not avoiding a bad tool.
If nobody on your team will own a codebase, pick neither: a hosted CMS or a visual builder is the more honest answer. And if you're weighing a hosted option too, we compare it with Payload in Sanity to Payload migration. When we build a site on Next.js, the CMS choice follows who edits and who maintains it.
