Payload CMS: When to Choose It Over Strapi and Sanity

Payload CMS is the right choice if your team is building a new application on Next.js, wants to keep the content schema directly in TypeScript code, and isn’t ready to pay a SaaS subscription for every editor. Strapi wins when you need a classic “CMS separate from frontend” architecture on a SQL database without being tied to a specific framework. Sanity is better if your team values a ready-made editorial interface with real-time collaborative editing more than full control over infrastructure.

In short: all three have open-source code or a generous free tier, but their deployment model and data ownership differ fundamentally. That difference should drive the choice - not the feature list on a vendor’s marketing page.

In June 2025, Figma acquired Payload - and that’s not a routine headless CMS market update. Figma’s official announcement confirms: the entire Payload team moved to Figma, the MIT license and source code remain open, but the managed Payload Cloud hosting stopped accepting new projects. For teams choosing a CMS today, self-hosted deployment isn’t an optional upgrade for later - it’s the only path from day one.

This changes the calculation. Previously you could start on Payload Cloud and deal with infrastructure later. Now infrastructure and DevOps time need to go into the project budget from the start. This article covers the concrete criteria for when Payload CMS wins against Strapi and Sanity, and when it loses, with a breakdown of architecture, deployment, and real total cost of ownership.

A team launching a product site or marketing landing page on Next.js usually picks the CMS last - after the frontend stack is already decided. If the CMS choice doesn’t match the frontend architecture, the developer spends weeks building glue layers: a separate API server, custom authorization, syncing types between the CMS schema and the application’s TypeScript types. Payload closes exactly this gap - at the cost of the CMS becoming part of the application’s backend rather than an independent service.

Payload CMS: an open-source headless CMS and full-stack TypeScript framework that describes content models in code and generates a REST/GraphQL API and admin panel from them. Starting with version 3.x, Payload installs directly into a Next.js project as part of the application, not as a separate service.

Comparing Payload CMS, Strapi, and Sanity

Architecture and Deployment: Three Different Ownership Models

Each of the three CMS platforms answers the question “where does the backend live” differently, and this determines infrastructure costs more than any feature on a marketing checklist.

Since version 3.x, Payload is co-located with Next.js: the admin panel, REST API, GraphQL endpoint, and Local API all run in the same process as the frontend. Local API is a set of Payload functions you can call directly from React Server Components without an HTTP request, within a single process. This removes the network hop between page rendering and data fetching, which directly reduces time to first byte.

The tradeoff: Payload requires a full Node.js runtime, not just static generation. You can’t deploy the admin panel to a purely static host - you need Vercel with serverless functions, Railway, Render, or your own server with Docker.

Strapi works as an independent API server: a frontend on any framework talks to it over HTTP. This is the classic headless architecture - you can deploy Strapi on one server and the frontend separately, even to a static CDN. Flexibility is higher, but you add a network layer between the application and the data on every uncached request.

Sanity removes the infrastructure question entirely: Studio, the API, and the asset CDN are hosted on Sanity’s side. Developers only need to configure the schema and connect the SDK on the frontend. The price is dependency on vendor infrastructure and a proprietary storage format.

When to Choose Payload CMS

Payload CMS is justified if most of these conditions apply:

• the project is built on Next.js 15+ from the start, not migrated from an older stack
• the team values type safety at every level: from the collection schema to component props
• you need full control over business logic at the API level - custom hooks on document save, complex role-based authorization
• infrastructure and its maintenance are already in place at the company or budgeted for from day one
• data must live in standard SQL or MongoDB with no vendor lock-in risk

According to GitHub search data, Payload’s repository star count grew from 8,200 to 24,300 over the past year - the steepest growth among the three CMS platforms, and it tracks the rise in popularity of the Next.js App Router. Developers starting new projects on Next.js 15 increasingly find Payload as the native CMS choice for this stack.

When to Choose Strapi

Strapi remains a strong choice if:

• the frontend isn’t tied to Next.js - the team works with Nuxt, SvelteKit, Astro, or a mobile app
• a relational SQL database is preferred over a document model
• you need a fast local dev start with no external dependencies
• the company has engineers ready to maintain a separate API server as part of the infrastructure
• keeping the “backend separate from frontend” architecture matters even if the frontend framework changes later

A detailed breakdown of Strapi paired with Astro and Next.js, including pricing and the @nuxtjs/strapi module, is covered in Sanity vs Contentful vs Strapi: Choosing a Headless CMS for a B2B Site.

When to Choose Sanity

Sanity remains the best option if:

• the content team has more than 3-5 people who need to edit the same documents simultaneously
• the company has no capacity for infrastructure and DevOps at all - not for the initial launch, not for ongoing maintenance
• the content model is complex and requires flexible queries - GROQ handles filtering and projections better than the REST endpoints of Payload or Strapi
• editors need a ready-made visual interface with real-time preview, without a developer customizing the admin panel

If your team is already comparing Sanity, Contentful, and Strapi without Payload on the list, that’s a separate breakdown with a pricing table and stack-by-stack analysis in Sanity vs Contentful vs Strapi.

Self-Hosted vs. SaaS: What Actually Goes Into the Cost

Self-hosted: running the CMS on your own server or cloud infrastructure, where the team bears full responsibility for updates, backups, monitoring, and security.

Payload itself is free - the MIT license doesn’t limit the number of records, users, or API requests. But self-hosted doesn’t mean free overall. Infrastructure for a production Payload project typically starts around 10 euros a month for a minimal server and grows with traffic and media volume.

The difference between a “free license” and “real total cost of ownership” is DevOps time: CI/CD setup, updating dependencies with each new Payload release, monitoring for outages, database backups. For a team without dedicated DevOps, these tasks fall on the same developer who writes features, and they cost real time even when they don’t show up on the hosting bill.

Sanity works differently here: the Growth plan at around $99/month includes an asset CDN, automatic scaling, and zero client-side infrastructure. For a small team without DevOps, this can be cheaper in real total cost of ownership than self-hosted Payload or Strapi, even at a higher nominal subscription price.

The rule is simple: self-hosted CMS pays off where infrastructure skills and site support are already part of the team or contractor. SaaS CMS pays off where those skills don’t exist and building them would cost more than the subscription.

Payload After the Figma Acquisition: What Changed for New Projects

Figma’s acquisition of Payload in June 2025 didn’t touch the open-source code: the GitHub repository stays public, the MIT license is unchanged, and the Payload team keeps developing the project, now inside Figma. For existing Payload Cloud users, nothing broke overnight - active projects keep running.

The change affects new projects: Payload Cloud, the company’s own managed hosting, is closed to new customers. Previously you could launch a project on Payload Cloud starting at $35/month for the Standard plan and not think about infrastructure at all. That option no longer exists for new users - self-hosted deployment has gone from an alternative to the only path.

It’s publicly known that the Payload team is now working on a product that could become part of a “CMS for designers” direction inside Figma - a bridge between design mockups and live site content. For engineering teams choosing a CMS in mid-2026, this means budgeting Payload’s infrastructure from day one of the project, rather than counting on managed hosting as a fallback.

Real Case: Launching a B2B Site on Next.js and Payload

In a typical B2B marketing site launch on Next.js 15 with Payload as the embedded CMS, setting up the first 5-7 collections - pages, articles, authors, media, redirects - takes 3-5 working days for a developer experienced with Next.js. The collection schema is described in TypeScript, and within a few hours of the first commit, a working admin panel with forms for every content type is already available.

import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'publishedAt',
      type: 'date',
    },
    {
      name: 'content',
      type: 'richText',
    },
  ],
}

Infrastructure for a project like this - a PostgreSQL instance at $15-25/month plus an application container on Railway or Render at $20-30/month. Total infrastructure cost lands in the $35-55/month range, against $99+ on Sanity’s Growth plan or several hundred dollars on Contentful’s plans. The data schema sits in plain SQL tables and doesn’t require an API export when switching platforms later - unlike Sanity’s proprietary format.

If the project starts from scratch rather than migrating from an old platform, the savings from the architecture choice are especially visible: you don’t pay for SaaS CMS features a team of 2-3 people physically won’t use, like complex approval workflows for 20 editors.

Who Payload CMS Is For

Payload CMS is a logical choice for startups and product teams that have already picked Next.js as their main framework and want a backend, authorization, and admin panel out of the box, without building it by hand. It fits engineering teams of 2+ people well, where one developer can maintain both the frontend and the CMS schema without switching between different query languages and different repositories.

Payload is less suited to large editorial teams with 15+ non-technical editors who need a polished interface at the level of Sanity Studio and real-time collaborative editing - for that scenario, the editor-experience gap is still noticeable.

Frequently Asked Questions

What Is Payload CMS in Simple Terms?

Payload CMS is an open-source TypeScript framework that handles backend routine: the database, REST and GraphQL APIs, authorization, file uploads, and an admin panel for editors. Developers describe the content structure - collections and fields - in code, and Payload generates a working management system from that description. Starting with version 3.x, Payload installs directly inside a Next.js project and runs in the same process as the application, rather than as a separate service.

Is Payload CMS Free?

The product itself, yes - the MIT license lets you use Payload for free with no limits on records, users, or API requests. Costs come from the infrastructure side: server, database, backups, and maintenance time. Payload Cloud, the managed hosting that used to remove this question for a fixed monthly fee, has been closed to new projects since mid-2025 following the Figma acquisition.

How Is Payload CMS Fundamentally Different From Strapi?

The main difference is the deployment model. Strapi runs as a separate API server, independent of the frontend: you can deploy it on one server and the site on another, and they talk over HTTP. Since version 3.x, Payload is co-located with the Next.js application - it runs in the same process, uses the Local API for direct calls without a network hop, and requires Next.js specifically as the frontend framework. Strapi is more flexible on frontend choice; Payload gives tighter integration and type safety specifically with Next.js.

Do You Need a Separate Server for Payload CMS?

Yes. Payload is a full-stack framework that requires a full Node.js environment, not just static generation. You can deploy it on Vercel with serverless functions, on Railway, Render, or your own server via Docker, but a purely static host with no backend won’t work. This is what sets Payload apart from Sanity, where all the CMS infrastructure lives on the vendor’s side and developers don’t need a separate server at all.

Can You Migrate Data From Sanity to Payload or the Other Way Around?

Technically yes, but the amount of work differs depending on direction. Payload and Strapi store data in standard SQL tables or MongoDB collections, so migrating between them is closer to an ordinary database migration. Migrating data out of Sanity is harder: content is stored in a proprietary NDJSON format, and GROQ queries and Portable Text structures don’t transfer directly into another CMS’s schema. You can export data from Sanity via API, but rebuilding the schema and all the queries for a new platform is a separate project spanning several weeks, not a one-time export.

If you’re choosing a CMS for a new Next.js project or comparing the real cost of self-hosted versus SaaS options - describe the task to the Exceltic.dev team. We’ll break down the architecture for your stack and estimate infrastructure costs for your specific content volume.