Your CMS Shouldn't Live in a Separate Repo

Payload CMS lets you define every collection, field, access rule, and hook in TypeScript -- checked into the same repo as your frontend, reviewed in the same pull request, deployed in the same pipeline. The software itself is MIT-licensed and costs $0. A professionally built Payload project typically runs $15,000 to $80,000+ depending on scope, with hosting starting as low as $35/month on Payload Cloud or under EUR 10/month if you self-host on a VPS.

We have shipped production sites on Payload since its early betas, and the pattern holds: teams that treat content modeling as code -- not as admin-panel clicking -- move faster and break less.

Why does it matter that your CMS config lives in your repo?

Most headless CMS platforms store your content model on their servers. When you need a new field, a changed relationship, or a modified permission, you log into a web UI, click around, and hope the staging environment matches production. Payload takes the opposite approach. Your schema is a set of TypeScript configuration files that sit alongside your components and API routes. According to the official Payload documentation, every collection, global, field type, hook, and access control function is defined in code.

This means three things in practice:

• Code review for content changes. A new blog field goes through the same PR process as a new API endpoint. Your team catches mistakes before they reach production.
• Reproducible environments. Spinning up staging, QA, or a new developer's local machine takes one command, not a 40-step runbook.
• Type safety end to end. Payload generates TypeScript types from your schema. Your frontend components consume those types directly -- no guessing what shape the API response will take.

How much does a Payload CMS project actually cost?

The software layer is free. The real cost is professional implementation and infrastructure. Here is what we see across engagements:

• Software license: $0 (MIT, commercially usable, no seat fees)
• Payload Cloud hosting: starts at $35/month per project
• Self-hosted infrastructure: under EUR 10/month on a basic VPS up to $500+/month at enterprise scale
• Professional development: $15,000 to $80,000+ depending on complexity, integrations, and access control requirements

Compare that to SaaS alternatives. Contentful runs $300/month or more once you pass five editors. Sanity's per-editor pricing reaches $1,200+/month at 50 users. With Payload, your ongoing cost is hosting -- no per-seat fees, no API-call limits, no surprise invoices when a blog post goes viral.

For a deeper look at how Payload stacks up against other headless options on price and architecture, we broke down the numbers in our Jamstack CMS comparison for 2026.

When should you choose Payload over Strapi, Sanity, or Contentful?

We reach for Payload when all three conditions are true: the team writes TypeScript, the project runs on Next.js, and long-term ownership matters more than quick editorial onboarding. That last point is worth being honest about -- Payload's admin panel is functional and extensible, but it is not as polished out of the box as Sanity's or Contentful's editor experience.

Here is how we think about the field:

• Strapi offers a mature, SQL-only architecture with battle-tested REST and GraphQL APIs. It is a solid pick for teams on existing relational databases. But its Node.js runtime uses more memory, and its content-type builder is UI-driven, which reintroduces the "click to configure" problem. We compared the two in detail in Payload 3.0 vs Strapi v5.
• Sanity excels at real-time collaboration and custom editorial workflows via its GROQ query language. Costs scale with datasets and API usage, though, and those pricing tiers start shaping architectural decisions sooner than most teams expect.
• Contentful is predictable, enterprise-ready, and well-documented. It is also $300+/month at the small-team tier and less flexible when you need complex relationships or granular permissions.
• Directus positions itself as a headless layer on top of an existing database. If your database schema is the source of truth and you want a CMS UI on top of it, Directus may be the better fit. But real application logic still needs a separate backend.

For teams evaluating GraphQL-native platforms, we also wrote a head-to-head on Payload CMS vs Hygraph.

What changed in Payload v3 with Next.js?

Payload v3 ships as a Next.js plugin. Your CMS admin panel and your frontend live in the same Next.js application -- same deployment, same database connection, same TypeScript types. This is not just a convenience; it eliminates an entire network layer.

Where other headless setups require your frontend to call out to a CMS API over HTTP, Payload's Local API lets you query content directly in React Server Components. No REST call, no GraphQL round-trip, no cold-start latency from a separate service. Setup time is 15 to 30 minutes for a fresh project, and you get REST and GraphQL endpoints automatically if you need them for mobile clients or third-party consumers.

The practical impact: fewer moving parts, fewer environment variables, fewer things that break at 2 AM.

What does Payload's access control actually look like in code?

This is where Payload earns its keep on complex projects. Access control is not a checkbox matrix in an admin screen -- it is a function that receives the authenticated user and returns a boolean or a query constraint. You can write multi-tenant rules, role-based field visibility, row-level restrictions, and document-level locks, all in TypeScript, all testable with your existing test suite.

We have built Payload projects with:

• Per-tenant data isolation for SaaS platforms serving 20+ clients from one deployment
• Field-level visibility rules that hide pricing data from external collaborators
• Hook-based workflows that trigger Slack notifications, sync to external ERPs, or generate PDFs on publish

Because these rules are code, they go through pull requests. No one grants themselves admin access by clicking a toggle at midnight.

Who should not pick Payload?

We believe in being direct about fit. Payload is the wrong choice when:

• Your editorial team needs a drag-and-drop visual builder without developer involvement. Storyblok or a WordPress page builder will get them moving faster.
• You need enterprise SLAs and dedicated vendor support on day one. Contentful and Sanity offer paid support tiers that Payload's community and Cloud plans do not yet match.
• Your team does not write TypeScript. The entire value proposition -- typed schemas, Local API, co-located config -- depends on TypeScript proficiency. A PHP or Python shop will be fighting the toolchain instead of benefiting from it.

If you are migrating off a traditional CMS and weighing whether Payload or Craft better fits your content model, we mapped out that decision in our Craft vs Payload comparison.

The long-term case for code-first content

After shipping dozens of CMS-backed sites, the pattern we see is this: projects that treat content modeling as infrastructure -- versioned, tested, deployed through CI -- accumulate less technical debt over 24 to 36 months than projects that rely on a vendor UI to define their schema. Payload does not solve every problem. Its admin panel has room to grow, its ecosystem is younger than WordPress or Drupal, and it deliberately stays out of the pre-packaged AI feature race that Sanity and Storyblok are chasing.

What it gives you is ownership. Your data sits in your database -- Postgres or MongoDB, your choice. Your schema sits in your repo. Your hosting sits on your infrastructure. There are no usage-based pricing surprises, no vendor roadmap dependencies, and no lock-in. For teams with TypeScript chops and a long time horizon, that trade-off pays for itself many times over.