Drupal vs Payload (2026): The CMS Inside Your App vs the Platform Behind It

Drupal and Payload are both open source, and that's where the similarity stops. Drupal is a content platform that sits behind your app — a separate system with its own database, admin UI, and release cycle, talked to over an API. Payload is a CMS that lives inside your app: as of Payload 3.0, it installs directly into a Next.js project's /app folder, and the admin panel is just another route in your codebase.

That's a real architectural choice, not a marketing line. Renting a content model that lives in a separate system means editors can change it without a deploy, but you're running two systems. Owning a content model that lives in your own TypeScript codebase means one deploy, one language, and full type safety end to end — but every schema change is a pull request.

This one is for teams choosing between "one Next.js app, one language, one deploy" and "a dedicated content system with an admin UI editors can reshape themselves." If you're comparing Drupal to a proprietary SaaS CMS instead, see Drupal vs Contentful or the broader headless CMS comparison.

The short answer

• Payload gets a TypeScript/Next.js team to a fully type-safe, working app faster than Drupal ever will.
• Drupal lets editors add and change content types from the admin UI; Payload requires a developer and a deploy for every schema change.
• Payload's Local API means server components can query the database directly, with zero API round trip — Drupal has no equivalent.
• Drupal ships editorial workflow and content moderation in core; Payload has drafts and versions, but no multi-stage, role-based moderation out of the box.
• Payload's footprint is one Node app you already run; Drupal is a second system with its own database, PHP runtime, and update cycle.
• If you're a single Next.js product with developers on hand for every content change, Payload is often the simpler choice. If editors need to own the content model, Drupal is built for that.

Side by side

Content modeling

Drupal's content model is a UI-driven system: content types, fields, entity references, and Paragraphs for reusable component content, all configured in the admin interface and exportable as configuration. An editor with the right permissions can add a field to a content type this afternoon. Every entity — nodes, users, taxonomy terms, media — gets revisions automatically, and the field system has been accumulating capability since Drupal 7.

Payload's content model is TypeScript code: collections, fields, blocks, and arrays defined in config files that live in your repo. That gives you something Drupal can't: the config is reviewable in a pull request, versioned in git alongside your app code, and Payload auto-generates TypeScript types from it, so your frontend gets autocomplete and compile-time safety on every field. The tradeoff is direct — adding a field means a code change, a review, and a deploy. There is no equivalent of a content author opening the admin UI and adding a text field to a content type without a developer in the loop.

Payload's blocks and arrays cover a lot of the same ground as Drupal's Paragraphs for flexible page layouts, and Payload's Lexical rich text editor plus live preview is a genuinely good editing surface. What it isn't is a drag-and-drop visual page builder for marketers — the editing model is blocks-plus-preview, not point-and-drag composition.

Developer experience and APIs

This is where Payload is built to win. Point it at Postgres, MongoDB, or SQLite and it generates REST and GraphQL APIs automatically from your TypeScript schema, with types flowing end to end from database to frontend. Because Payload runs inside your Next.js app, server components and server actions can use the Local API to query the database directly — no HTTP round trip, no separate API layer to reason about. That's a real architectural advantage for a Next.js team: fewer moving parts, one language, one type system.

Drupal's API story is broader but more assembled. JSON:API has been in core since Drupal 8.7 (2019) and every entity gets an endpoint automatically, with no configuration. GraphQL exists but isn't core — it comes from the contributed graphql_compose module, which generates a schema from your content types. REST is in core too. None of this gives you Payload's zero-round-trip Local API, because Drupal is a separate system by design; a Next.js frontend talks to it over the network no matter what.

The practical read: a TypeScript team building one Next.js product gets to a working, type-safe app faster in Payload. A team that needs a content backend serving multiple frontends, or that wants API access without touching a codebase, is better served by Drupal's API-first posture.

Editorial experience

Drupal ships an editorial workflow engine in core: Content Moderation and Workflows let you define custom states — draft, in review, legal review, published — and control who can move content between them by role. Combined with fine-grained permissions and full revision history on every entity, this is built for organizations where content passes through multiple hands before it goes live.

Payload has drafts and versions built in, and live preview so editors can see changes before publishing. What it doesn't have, out of the box, is a comparable multi-stage, role-based moderation engine — there's no equivalent of "this piece of content must pass through three named roles before it publishes." Access control functions in Payload are powerful and can be built to approximate parts of this, but it's something you construct in code, not something you configure in an admin screen.

If your editorial team is small and works directly with developers, this gap doesn't matter much. If you have a marketing org with an approval chain and non-technical editors who need to self-serve content structure changes, Drupal's editorial tooling is materially ahead.

Pricing and total cost of ownership

Both are free, open-source software. Neither charges per seat, per entry, or per API call. The cost is what you build around them.

Worked example. A team with 10 editors, 3 locales, 50,000 entries, and 2 million API calls a month:

• Drupal: Self-hosted infrastructure for a site this size typically runs $50–$500/month in cloud costs, depending on traffic and caching setup, plus ongoing developer time for updates, security patches, and PHP version migrations — a few hours a month at minimum. The range is wide because it depends on your hosting choice: raw cloud infra at the low end, or Acquia/Pantheon enterprise Drupal PaaS at the high end, which commonly runs into the thousands per month on custom quotes.
• Payload: Self-hosted, Payload runs as part of your existing Next.js deployment — on Vercel, Netlify, or your own Node host — so there's often no separate infrastructure line item at all; you're paying for the app hosting you'd need anyway, plus your database (Postgres, MongoDB, or SQLite). Payload Cloud is available as a managed option if you'd rather not run it yourself; check payloadcms.com for current plan details, since Payload doesn't publish a fixed public price list the way some SaaS CMSs do.

The honest comparison: Payload's marginal infrastructure cost for a single Next.js app is often close to zero, because it rides on hosting you already have. Drupal is a second system, so it always adds its own hosting and maintenance line, whether that line is $50 or $5,000 a month.

Operations, hosting, and security

Drupal is a separate PHP application: its own database, its own runtime, its own release cycle. Self-hosted, you own applying security releases from Drupal's dedicated Security Team, managing Composer dependencies, and handling PHP version upgrades. That's real operational weight, and it doesn't go away — decoupled.io and other managed platforms exist specifically to take it off your plate.

Payload has no separate runtime to operate — it's part of your Next.js deployment, so it inherits whatever hosting and CI/CD pipeline you already run for that app. There's no second database to provision unless you count the one Payload itself uses (which many Next.js apps need anyway). The honest tradeoff: Payload is younger, so its operational track record — patch cadence, upgrade paths across major versions — is shorter than Drupal's two decades of production history at scale.

Lock-in and exit

Neither locks you into a proprietary vendor. Drupal's content lives in a standard MySQL or PostgreSQL database with a documented schema; you can export config and content and run it anywhere Drupal runs. Payload's content lives in whichever database you chose (Postgres, MongoDB, or SQLite), and because the schema is your own TypeScript code, there's no proprietary format to reverse-engineer — you already own the source of truth.

Where they differ is coupling to the frontend. Drupal is decoupled by design — the backend has no opinion about what consumes its API. Payload is architecturally married to Next.js in its 3.0 form: it installs into a Next.js app and its Local API advantage depends on that pairing. Moving off Next.js later means moving off that specific integration, even though the underlying data and MIT-licensed code remain yours.

Choose Payload if…

• You're building one Next.js application and want a single codebase, single language, single deploy.
• End-to-end TypeScript type safety, from database to frontend, matters more than an editor-facing admin UI.
• Your team is developers first, and content changes routinely go through code review anyway.
• You want to avoid running and patching a second backend system.

Choose Drupal if…

• Non-technical editors need to add or change content types without waiting on a deploy.
• You need real editorial workflow: multi-stage, role-based moderation and approval chains.
• You're serving multiple frontends or brands from one content backend, not just one Next.js app.
• Localization maturity, fine-grained permissions, and a large talent pool of available developers matter for the long haul.

The best of both worlds

decoupled.io is managed headless Drupal — you get Drupal's entity system, fine-grained permissions, and full multilingual support, without running a server yourself. Every space ships with JSON:API and GraphQL, an auto-generated typed TypeScript client, and the Puck visual page builder for drag-and-drop editing with live preview — a visual composition tool Payload doesn't offer.

It also ships 25+ MCP tools out of the box, so AI agents like Claude or Cursor can work against your content model directly, something Payload has no native equivalent for today.

What it doesn't match: Payload's Local API. Because decoupled.io's Drupal instance is still a separate system from your Next.js frontend, there's no zero-round-trip database access from your server components the way Payload gives you inside its own app — you're always calling an API, even a fast, typed one. If that specific integration pattern is the reason you're evaluating Payload, decoupled.io doesn't remove the network hop; it makes the hop typed, fast, and easy to work with instead.

See decoupled Drupal for what that architecture means in practice, or the headless Drupal guide for the JSON:API/GraphQL/Next.js integration details. Pricing is on pricing; see the Decoupled.io vs Payload compare page for the vendor-style side-by-side.

FAQ

Can I migrate from Payload to Drupal? There's no packaged migration tool between the two today. Payload's REST and GraphQL APIs make content export straightforward, and because you own your TypeScript schema, you know exactly what you're moving. The work is remodeling Payload's collections and blocks into Drupal's entity/field system and Paragraphs, which is a real mapping exercise, not a one-click import.

Is Payload actually free? Yes — Payload is MIT-licensed and free to self-host indefinitely; there's no paid tier gating core CMS features. Your cost is the infrastructure you host it on (often infrastructure you already run for your Next.js app) plus developer time to build and maintain the schema. Payload Cloud is available if you want a managed option instead of self-hosting.

Is Drupal harder to learn than Payload? For a JavaScript developer, yes, at least at first — Payload's config-as-code model in TypeScript is immediately familiar, while Drupal's entity/field system, Views, and permissions model take longer to learn. The tradeoff is that Drupal's learning curve buys editor-facing flexibility Payload doesn't have: once learned, non-developers can reshape the content model themselves.

Which one has better AI agent support? Neither has native MCP tooling as of this writing — Payload doesn't ship MCP support, and Drupal doesn't include it in core. decoupled.io adds 25+ MCP tools on top of managed Drupal specifically for AI agent workflows, which is the gap this article's "best of both worlds" section addresses.

Part of the Drupal vs the headless CMS field series.