corpusctl vs Payload: a CMS that isn't inside your frontend

But if you are choosing a CMS this month, the facts are: the managed offering is not taking new projects, and the current one has a migration in its future. Payload the open source project is unaffected and remains self-hostable anywhere you can run a Next.js app.

Whether an acquisition is good news depends on which side of it you are on. Figma's resources will likely make Payload better. They will also make Payload's roadmap answer to Figma's strategy — and design-tool strategy is not the same as content-infrastructure strategy.

#The deeper difference: Payload lives inside your app

This is the part that outlives any acquisition.

Payload runs inside your Next.js application. That is its central design decision and the source of its best feature — a local API that skips HTTP entirely, because the CMS and the frontend share a process. For a single Next.js product with one team, this is a genuinely excellent developer experience and it is why Payload is winning developers.

It also means your CMS and your website share a deploy, a runtime, and a scaling unit. A traffic spike on the public site is a traffic spike on the thing your editors are using. A frontend rebuild is a CMS rebuild. Changing frontend framework is not a frontend project.

corpusctl splits the two paths on purpose:

Write path — panel → API (NestJS) → PostgreSQL → build pipeline.

Read path — visitor → nginx edge cache → immutable file in object storage.

They meet at exactly one point: the build pipeline writes to object storage. Publishing renders the content to an immutable, hash-addressed file and refreshes a manifest. The visitor's client resolves the slug to a manifest shard locally, then fetches that address from the edge — cacheable for thirty days, because the same address can never return different content.

Consequences that follow from the split:

• Visitor traffic never reaches the API or the database. Load on the write side is fully independent of the read side.
• Your frontend framework is not a CMS decision. The core render tree is framework-agnostic; React, Vue and Next.js adapters are thin layers on top. Migrating from Next.js to something else does not touch the CMS.
• There is no per-call meter, because there is no per-call.

#Multi-project, and where isolation is enforced

Payload supports multi-tenancy as a documented pattern you implement in your own application code.

In corpusctl it is in the core, alongside auth and the module registry: one panel, unlimited spaces, a user carrying a separate role in each. Isolation is enforced by PostgreSQL row-level security — in the database, below the layer where an application-level filter can be forgotten.

The argument for RLS is narrow and, I think, decisive: application-level isolation works until the one query that skipped the filter. That query gets written eventually, by someone in a hurry, in a module nobody reviews closely. RLS makes the leak impossible underneath the mistake.

#44,000 stars, 79 Stack Overflow questions

A number worth sitting with. As of 17 August 2026, Payload has about 44,000 GitHub stars and roughly 79 Stack Overflow questions. Strapi, for comparison, has about 73,000 stars and 2,800 questions.

That gap is what fast growth looks like: a large, enthusiastic, recent user base whose troubleshooting corpus has not been written yet. When you hit an edge case at 2am, the odds that someone has already published the answer are meaningfully lower.

This cuts against corpusctl too — we are smaller than both. It is offered as an observation about maturity, not a point scored.

#The operational parts

Modules. Every corpusctl feature is a module: media, search, webhooks, SEO, GraphQL, import, analytics. disabled preserves data and resumes on re-enable; uninstalled clears it and asks twice. A plan downgrade sets modules to disabled and never deletes data — enforced in the codebase, not promised in a support article.

Zero-style renderers. Block renderers ship with no default CSS at all. Every block type is overridable; an unknown type is skipped rather than throwing. If rendering a block requires framework-specific code, the abstraction is in the wrong place.

Durable webhooks. Deliveries sit in a queue with exponential backoff and jitter. An hour of receiver downtime does not lose events.

Stable error codes. Every API error carries a permanent code (CORPUS_E_9127) plus a docs link. Messages are translated into seven languages; codes are not. Client code binds to the code, so improving a message never breaks an integration.

#Where Payload wins

Developer experience for a Next.js team. TypeScript-native, config-as-code, and the local API. If your product is one Next.js app and your team is comfortable owning the deployment, this is hard to beat.

Momentum. Trends breakout, millions of npm downloads a month, and now Figma's engineering resources. That is real.

Admin UI customisation. Payload's admin is React components you can replace outright. corpusctl's panel is configurable, not arbitrarily replaceable.

Self-hosting is free and always has been. No qualifier needed.

#The honest summary

Pick Payload if you are a Next.js team that wants config-as-code and the local API, and you are comfortable self-hosting.

Pick corpusctl if you want the CMS outside your frontend's deploy, several projects from one panel, and isolation enforced by the database.

Payload Cloud status and FAQ quotations taken from payloadcms.com/cloud-pricing on 17 August 2026. This is a fast-moving situation — re-check before quoting.

See the architecture → · Read the docs →