Payload vs Strapi in 2026: Which Self-Hosted Node CMS?

If you're picking a self-hosted Node CMS in 2026, the shortlist almost always comes down to Payload vs Strapi. Both are open source, both are TypeScript-friendly, and both will run on your own server — but they disagree on almost everything else.

TL;DR verdict: Pick Payload if your team lives in TypeScript and Next.js, wants the content model in version control, and treats the CMS as part of the application codebase. Pick Strapi if you need a GUI content-type builder that non-developers can drive, a framework-agnostic API backend, and a bigger plugin marketplace. Payload is the better developer tool; Strapi is the better team tool. Neither is wrong — they're built for different workflows, and the rest of this post is about figuring out which workflow is yours.

Quick disclosure up front: we don't sell either product. We build a different CMS (more on that at the very end), so we have no horse in this specific race.

Here's the full picture before we go dimension by dimension:

Content modeling: config-as-code vs GUI builder

Payload defines every collection, field, and access rule in TypeScript files that live in your repo. Strapi gives you a visual content-type builder in the admin panel and writes schema JSON for you. Payload's approach wins for teams with code review and CI; Strapi's wins when non-developers shape the model.

This is the single biggest philosophical split between the two, and it predicts almost every other difference.

In Payload, a blog post type is a CollectionConfig object: fields, validation, hooks, and access control as plain TypeScript. You get autocomplete on your own content model, types generated for the frontend, and every schema change shows up in a pull request. Rolling back a bad field change is git revert. Spinning up a staging environment with the same model is just deploying the same code.

In Strapi, you open the content-type builder, click "Add field," pick from a visual list, and save. Strapi restarts and regenerates schema files on disk. Those files can be committed to git — and you should — but the editing experience is GUI-first, and in production mode the builder is locked, so model changes have to flow through a dev environment anyway.

The honest trade-off: Payload's approach front-loads work on developers. A marketer can't add a field to a landing page type without a deploy. Strapi's approach is faster for day one and friendlier to mixed teams, but schema drift between environments is a real failure mode if your team is sloppy about committing generated files. We wrote a deeper piece on this exact split in config-as-code vs GUI-first CMS if you want the full argument.

Framework coupling: Next.js native vs framework-agnostic

Payload 3.0 made a bet nobody else made: the CMS installs into your Next.js app — same repo, same deploy, admin panel served from a route. Strapi stays a standalone Node server that doesn't care what your frontend is. If you're not on Next.js, this dimension alone decides it: Strapi.

Payload v3 (stable since late 2024) is genuinely different from every other headless CMS. There's no separate CMS server. Your payload.config.ts sits next to your Next.js code, the admin UI renders through the App Router, and you can query content with the Local API — direct function calls to the database layer, no HTTP round trip. Server components fetching content without a fetch call is a real performance and DX win.

The cost is obvious: you're coupled to Next.js. Payload's docs are upfront that v3 is Next.js-native. If your frontend is Nuxt, SvelteKit, Astro, or a mobile app, Payload still serves REST and GraphQL like any headless CMS — but you're carrying a Next.js app whose only job is hosting the admin panel, which is a weird shape for a Vue shop.

Strapi is deliberately boring here, and that's a compliment. It's a Koa-based server that exposes APIs. Your frontend is your business. One Strapi instance can feed a Next.js site, a Flutter app, and a kiosk display without anyone arguing about frameworks. For agencies juggling different client stacks, that neutrality matters more than Payload's integration depth.

Admin UI: who gives editors a better day?

Both admins are far ahead of the WordPress-era bar. Payload's admin is faster, cleaner, and built from customizable React components — you can swap nearly anything. Strapi's admin is friendly and consistent but customizing beyond its design system means fighting it. Editors like both; developers extending the UI prefer Payload.

Payload's admin panel in v3 is server-rendered React with a restrained, modern look. The killer feature is replaceability: custom field components, custom views, custom dashboards are all just React components you register in config. Live preview and visual editing have matured a lot through 2025. If you've seen the wave of shadcn-styled admin panels, Payload fits that aesthetic conversation — we compared the approaches in shadcn CMS vs Payload.

Strapi's admin runs on its own design system and got a meaningful polish pass in Strapi 5. Content editing, draft & publish, and the media library are solid and well-documented. Where it frays: deep customization. Injecting custom UI happens through extension points and plugin APIs, and the moment you want something the design system didn't anticipate, you're reading source code. Most teams never hit that wall. Teams that do, complain loudly.

One more practical note: Payload's field types are richer out of the box for developer-shaped content — blocks, arrays, relationships with typed depth. Strapi's dynamic zones cover similar ground but generate messier API responses.

APIs: REST, GraphQL, and Payload's Local API

Both ship REST and GraphQL, so call it a tie on paper. In practice Payload's auto-generated APIs are cleaner and its Local API (direct database-layer calls, no HTTP) is a genuine differentiator inside Next.js. Strapi 5 finally flattened its infamous nested REST responses, which fixed its biggest API complaint.

Strapi v4's REST format was a running joke: every response wrapped in data.attributes, relations nested three levels deep, frontend code full of unwrapping helpers. Strapi 5's Document Service API flattened responses, and as of 2026 the REST output is pleasant to work with. GraphQL is an official plugin rather than core, and it works fine for typical query shapes.

Payload generates REST and GraphQL endpoints from the same TypeScript config, with generated types you can share with the frontend. The Local API is the standout: inside your Next.js server code, payload.find({ collection: 'posts' }) hits the database directly. No serialization tax, no network hop, full access-control rules still applied. For statically generated or server-rendered sites, that's measurably faster builds and simpler code.

Where Strapi pulls ahead: API tokens, role-based API permissions, and rate limiting are all configurable from the admin GUI, which suits teams handing API access to third parties. Payload expresses the same things in code — powerful, but someone has to write it.

Plugins and ecosystem

Strapi wins on raw ecosystem size. Its marketplace has hundreds of plugins — SEO, i18n helpers, import/export, preview, payment integrations — many installable in minutes. Payload's plugin list is smaller but higher-trust: official plugins for SEO, form builder, search, nested docs, and cloud storage, all TypeScript-typed and maintained in the core orbit.

The numbers favor Strapi, but read the quality bar honestly:

1. Strapi marketplace plugins vary a lot. The popular ones (SEO, config sync, import/export) are battle-tested. The long tail includes plugins abandoned at v4 that never made the v5 jump — check the compatibility badge before depending on anything.
2. Payload plugins are mostly first-party. Fewer options, but they upgrade in lockstep with core and they're typed end to end. Community plugins exist but the culture leans toward "write it yourself in config" because hooks and custom components cover most needs without a plugin at all.
3. Strapi customization happens through plugin APIs; Payload customization happens through config. Need a custom field type in Strapi? You're writing a plugin. In Payload? You're writing a React component and referencing it in config. The Payload route is less ceremony.

If your project plan depends on gluing together off-the-shelf plugins, Strapi gives you better odds. If you expect to build custom behavior either way, Payload's hook system (beforeChange, afterRead, and friends) is the nicer foundation.

Database support

Strapi supports Postgres, MySQL, MariaDB, and SQLite — relational only, MongoDB was dropped back in v4. Payload started MongoDB-first and added Postgres and SQLite through Drizzle adapters. If your org standardizes on MySQL, Strapi is your only option here. If you want MongoDB, Payload is the only option.

A few practical notes from the field:

• Payload + Postgres matured a lot through 2025, but Payload's roots are MongoDB, and some of its data shapes (blocks, arrays, localized fields) map more naturally to documents. On Postgres these become joined tables that Drizzle manages for you — it works, but inspect the generated schema before you commit to writing raw SQL reports against it.
• Strapi + Postgres is the default, best-tested path and what Strapi Cloud runs. SQLite is for local dev, not production.
• Migrations: Payload generates Drizzle migrations from config changes — schema changes are explicit files in your repo. Strapi auto-syncs schema on startup in dev, which is convenient until two developers' local databases drift apart.

Upgrade history and breaking changes

Both projects have made their users rewrite things. Strapi's v3-to-v4 migration (2021) was a near-total rewrite with no automated path, and v4-to-v5 changed the REST format and data model again — though with codemods this time. Payload's v2-to-v3 jump rebuilt the product around Next.js. Budget for major-version pain with either.

The track records, briefly:

1. Strapi v3 → v4 (2021): new plugin API, new database layer, MongoDB dropped, no migration tool at launch. Teams ran v3 in production for years because the jump was so expensive.
2. Strapi v4 → v5 (2024): Document Service replaces Entity Service, flattened REST responses, draft & publish reworked. Codemods cover a lot, plugins needed rewrites. As of 2026 the v5 ecosystem has mostly caught up.
3. Payload v1 → v2 (2023): admin bundler swap and config changes — moderate pain.
4. Payload v2 → v3 (2024): the big one. Payload became Next.js-native, which meant restructuring your project around an app it used to sit beside. The payoff was real, but it was a migration project, not an afternoon.

One more 2026-relevant fact: Figma acquired Payload in 2025. The team has said the project stays open source under MIT, and through early 2026 development pace has held up. Still, an acquisition changes incentive structures over time — worth knowing if you're betting a five-year project on it. Strapi remains independent and VC-backed, which carries its own different-shaped risk.

Hosting and ops: what running it actually costs you

Both are Node apps you have to keep alive — neither runs on shared hosting. Payload v3 deploys anywhere Next.js does, including Vercel, which is the easiest path. Strapi wants a long-running server with real memory; plan for 2GB RAM and a process manager. Strapi is the heavier ops commitment.

Concretely, a production Strapi instance means: a VPS or container, Postgres, a process manager (PM2 or systemd), a reverse proxy, and an upload strategy (local disk or S3-compatible storage, because container filesystems are ephemeral). Strapi's memory appetite is well known — 1GB instances fall over under moderate admin use, so budget 2GB minimum. None of this is hard for a team that already runs Node services. All of it is real work for a team that doesn't.

Payload v3 inherits Next.js deployment options. Vercel works, including serverless — with the usual caveats around long-running hooks and cold starts against your database. A plain VPS with next start behind Nginx works too, and gives you the most predictable behavior. Because the CMS and frontend are one app, you run one deploy pipeline instead of two, which is an underrated ops simplification.

Self-hosting either is entirely doable. Just be honest in your estimate: it's a database, backups, monitoring, Node version upgrades, and security patches — forever. That's the price of "free."

Licensing and cloud pricing

Both cores are MIT-licensed as of 2026, so self-hosting is free in both cases. The difference is what's gated. Strapi holds back enterprise features — SSO, audit logs, review workflows — for paid tiers. Payload keeps nearly everything in the open-source core and charges for hosting and enterprise support instead.

Strapi's model: the Community Edition is MIT and genuinely usable in production. The Enterprise Edition and Strapi Cloud add SSO, audit logs, content history at higher tiers, and review workflows. Strapi Cloud pricing as of 2026 starts around $29/mo for the entry tier and climbs steeply — the Pro and Scale tiers run roughly $99 and $499/mo. Check current pricing before you plan; these numbers have shifted before.

Payload's model: the core, including access control, versions, localization, and live preview, is MIT. Payload Cloud (hosting) starts around $35/mo as of 2026, with enterprise contracts for SSO integrations, dedicated support, and SLAs. The notable part is how few features are paywalled — what you self-host is essentially the whole product. Post-Figma-acquisition, this hasn't changed yet; whether it holds long-term is anyone's guess.

If "every feature, self-hosted, $0" is the requirement, Payload currently gives you more of the product for free. If you want managed hosting either way, the cloud bills land in the same ballpark for small projects and diverge at scale.

Verdict: which one, for which team?

There's no single winner, but there are clear lanes:

1. TypeScript product team building on Next.js → Payload, and it's not close. Config-as-code, Local API, one repo, one deploy. This is the exact center of Payload's target.
2. Agency serving clients on mixed stacks → Strapi. Framework neutrality, GUI modeling that clients can understand, and a plugin marketplace that covers common client asks.
3. API backend for mobile apps or multiple frontends → Strapi, slightly. A standalone API server is the natural shape for this; Payload works but drags Next.js along.
4. Content-heavy site where editors outnumber developers → lean Strapi for the GUI builder, but demo Payload's admin to your editors first — some teams prefer it.
5. MongoDB shop → Payload, by elimination.
6. MySQL-standardized org → Strapi, by elimination.
7. Long-lived project where upgrade risk matters most → genuinely a coin flip; both have broken users twice. Pin versions, budget for majors, and read the changelog culture of each repo before committing.

And if neither fits, the field is wider than these two — we keep a current list in best Payload alternatives in 2026.

A disclosed alternative if Node ops is the dealbreaker

Full disclosure: we build UnfoldCMS, a self-hosted CMS on Laravel/PHP. If everything above sounded good until the ops section — keeping a Node process alive, the 2GB RAM floor, the deploy pipeline — that's the gap we sit in. UnfoldCMS runs on ordinary PHP hosting, including shared hosting, ships a REST API under /api/v1/*, and uses a shadcn-based admin UI. We've written direct comparisons if you want the honest matchup: UnfoldCMS vs Payload and UnfoldCMS vs Strapi. If you're staying in Node land, everything above stands on its own — pick the lane that matches your team.

FAQ

Is Payload better than Strapi? For TypeScript teams on Next.js, usually yes — config-as-code and the Local API are hard to beat. For mixed teams, non-Next.js stacks, or plugin-driven projects, Strapi is the more practical choice. "Better" depends entirely on who's doing the modeling and where the frontend lives.

Can I use Payload without Next.js? Technically yes — Payload v3 exposes REST and GraphQL, so any frontend can consume it. But the CMS itself runs inside a Next.js app, so you'll deploy and maintain Next.js either way. If Next.js isn't in your stack at all, Strapi's standalone server is the cleaner fit.

Is Strapi still free in 2026? Yes — the Community Edition is MIT-licensed and fine for production self-hosting. Enterprise features like SSO and audit logs require paid tiers, and Strapi Cloud starts around $29/mo as of 2026. The free core covers most small-to-mid projects.

Which is easier to self-host, Payload or Strapi? Payload, slightly — it deploys anywhere Next.js does, including Vercel, and it's one app instead of CMS-plus-frontend. Strapi needs a long-running Node server with around 2GB RAM, a database, and a process manager. Both are far more ops than a PHP CMS on shared hosting.

Sources & methodology

This comparison is based on the official Payload and Strapi documentation, changelogs, and pricing pages as reviewed in early 2026, plus hands-on testing of Payload 3.x and Strapi 5.x in local and VPS environments. Pricing and licensing details are stated "as of 2026" and do change — verify against payloadcms.com and strapi.io before budgeting. We build a competing CMS in a different ecosystem (PHP), disclosed above; neither vendor sponsored or reviewed this post. Corrections welcome — if we got a detail wrong, tell us and we'll fix it.