Strapi vs Payload

Strapi and Payload are the two Node.js headless CMS projects most people compare when they want content types, an admin panel and an API without paying for a hosted service. Both are rated 3 out of 5 to deploy, both run on PostgreSQL, and neither publishes a ready-made production image: in our tests we scaffolded a project with each one's installer and built it ourselves. The difference is where the project lives. Strapi is a standalone Node.js server you scaffold and deploy. Payload is a framework that installs into a Next.js app, so the CMS and your website can be one codebase.

How you model content

Strapi is built on Node.js, TypeScript and React. You design content types in an admin Content-Type Builder, and Strapi generates a REST API, role-based permissions and a media library for them. GraphQL is available as a plugin.

Payload is code-first. Collections, access control, the admin panel, and the REST, GraphQL and Local APIs are all defined in TypeScript config. The Local API means code running inside the same Next.js app can query content directly instead of going over HTTP.

If you want to click content types into existence and let an editor adjust them, Strapi's builder is the shorter path. If you want the schema reviewed in pull requests like any other code, Payload's config is the better fit.

Licence

Payload is MIT. Strapi's core is MIT with proprietary enterprise modules, so read which features you rely on before committing. For a plain self-hosted content API the free core is what you will run; the licence line matters when a feature you need turns out to sit in the enterprise part.

What the installs looked like

Both installs passed our verification on Ubuntu 26.04, and both took more steps than a one-file Compose project. Strapi's route is create-strapi pinned to a version, then a production Dockerfile from Strapi's Docker docs, then Compose with Postgres. Payload's is create-payload-app with its blank template, after which we had to turn on standalone output in next.config.ts, copy the template's .npmrc into the build, and give the unprivileged runtime user a writable media folder for uploads. Payload also needs a first migration created and applied for Postgres in production, because schema push is development-only.

None of this is hard, but it is why neither is a two-minute install. Budget an afternoon, not a coffee break.

Footprint

Our minimum RAM figure is the same for both, 2 GB, and it is an estimate that reflects the build step. Idle on our GCP test box (e2-standard-2) we measured about 189 MB for Strapi and about 100 MB for Payload, with roughly 17.5 GB and 10.5 GB of disk used respectively once the images were built. Treat the 2 GB as headroom, not a prediction of idle use; we did not isolate what drives it.

Which to choose

Choose Strapi if editors need to change the content model from the admin UI, or if you want a CMS that stays separate from whichever frontend you build.

Choose Payload if your frontend is already Next.js and you want the CMS to live in the same app, with the schema in TypeScript and the MIT licence with no enterprise carve-out.

Not the only two options

Both are headless CMS options in the Backend & BaaS category; a third approach is layering over an existing database, covered in Strapi vs Directus and Payload vs Directus. Details for each app are on the Strapi and Payload pages, and if you are replacing a hosted backend, see our Firebase alternatives page.