Three products, one category, and from outside they look interchangeable: open source, headless, self-hostable, an admin panel, an API.
They are not interchangeable, and the differences are not feature differences. Each one starts from a different premise about what it is, and that premise decides who on your team can work with it and what running it involves. The clearest way to see that is to read what each one says about itself.
Everything quoted below comes from each vendor’s own documentation, read at its own address on 2026-08-28. No price, plan tier, limit or benchmark appears anywhere on this page, because vendor numbers move and this site does not publish one without a source and a date.
What each one says it is
Strapi. Its documentation describes it as “an open-source headless CMS that gives developers the freedom to choose their favorite tools and frameworks,” and as “a flexible CMS whose admin panel and API are extensible, and which every part is customizable to match any use case” (Strapi 5 Documentation, read 2026-08-28).
Note who that sentence is addressed to. Developers, and the freedom being offered is freedom of tooling around it.
Directus. Its documentation opens with “A backend your whole team can use,” and describes the product as wrapping “any SQL database to get instant APIs, a Studio your team can actually use, and a native MCP server” (Directus Docs, read 2026-08-28).
That is a different premise entirely. Directus is describing itself as a layer over a database you may already have, rather than as a place to put content.
Payload. Its documentation states “Payload is the Next.js fullstack framework,” and describes writing “a Payload Config” to “instantly get a full Admin Panel, a database with migrations, REST and GraphQL APIs, authentication, access control, file storage, live preview, and more, all in one open-source TypeScript codebase you own and deploy anywhere” (Payload Documentation, read 2026-08-28).
A third premise. Payload is describing itself as a framework you build with, in a specific ecosystem, rather than as an application you install.
Three sentences, three different products. One is a CMS for developers to extend, one is an interface over an existing database, one is a framework inside a JavaScript stack.
Why the premise matters more than the feature list
Because it decides three things a feature comparison will not tell you.
Where the content model lives. Directus’s premise implies the schema is in the database and the product surfaces it. Payload’s premise implies the schema is in a config file in your codebase. Strapi sits between. That difference decides whether changing a content type is a database operation, a code change and a deploy, or a click in an admin panel.
It also decides how a change moves between environments, which is the thing that bites in month three rather than in week one. This is the same class of problem as the one covered in content model migration between systems: a model that lives in code and a model that lives in a UI move very differently.
Who can change things. If the content model is in a config file, a marketing team cannot add a field. If it is in an admin panel, they can, and you now need a rule about who does. Neither is better. They are different operating arrangements and they suit different teams.
What you are committing to operationally. A product that describes itself as a framework in a specific stack is a commitment to that stack. A product that wraps an existing SQL database is a commitment to keeping that database. Those commitments outlast most feature preferences.
What “self-hosted” costs on all three
The licence is free. The operating is not, and it is identical in shape across all three: updates, verified backups and restores, monitoring, scale, and a person who knows how the thing was set up.
Directus’s own docs describe the arrangement neutrally: “Run Directus on your own infrastructure with Docker or your platform of choice” (read 2026-08-28). That sentence is accurate and it contains an entire operations function inside the words “your own infrastructure”.
The question that actually decides whether self-operating is viable is not technical capacity, it is whether you can name a second person who could handle an incident. Self-hosted or cloud: who is on call at 2am works through that question, and it applies to all three of these products equally.
All three also have paid hosted offerings from their own vendors. That option exists and it is frequently the right one, and this page names no prices for any of them.
What this page will not do
It will not declare a winner, and that is a rule rather than a hedge. The map’s own instruction on this row is that it must not become a ranked roundup. A ranking would require weightings that are yours rather than mine, and the three products are not answering the same question closely enough for a ranking to mean anything.
It will not quote a benchmark, a limit or a price. None was read at its source in this session, and a stale number on this subject is a wrong number.
It will not tell you which is easiest. Ease depends entirely on your team’s existing stack, and a product that is trivial for a team already in one ecosystem is a substantial commitment for a team that is not.
The test worth running instead
Rather than reading three comparison tables, run the same short test on each candidate, with the people who will actually use it.
Model one real content type, not a blog post. The one on your site that is awkward: the one with a repeating section, the one with a relationship to another type, the one with a field nobody can name. If a platform makes that easy, it will make the rest easy.
Have a non-developer create and publish one item. Not a demo, one of yours, with a real image and real relationships. Watch where they stop.
Change the model after content exists. Add a required field to a type that already has fifty entries. What the product does at that moment tells you more than any feature list.
Export everything and read the file. This is the one most people skip and it is the one that determines whether you can ever leave. Exporting your content from a CMS covers what to look for in the file, and the general finding of this site’s migration cluster is that the export is almost always less complete than the interface suggests.
That test takes an afternoon per candidate and it answers questions no page can.
Where open source stops protecting you
One caution to carry into any of these three, and it is the subject of its own article.
Open source protects the code. It does not automatically mean your content is portable, that your custom extensions survive a major version, that a hosted tier’s behaviour matches the self-hosted one, or that the project will still be maintained in five years. Those are separate questions with separate answers, and they are what what happens if the vendor shuts down or gets acquired is about.
The short version
- Strapi describes itself as an extensible CMS for developers. Directus as a layer over an existing SQL database. Payload as a framework inside a specific stack. Their own words, read 2026-08-28.
- The premise decides where the content model lives, who can change it, and what you are committed to.
- Self-hosting costs the same in operations across all three, and the deciding question is who the second person is.
- No winner is declared here and no number is published, deliberately.
- Model one awkward content type, have a non-developer publish, change the model after content exists, and read the export file.
