Strapi vs Directus vs Payload

Strapi, Directus and Payload are the three self-hosted headless CMS options developers shortlist. This page shows which one fits which team, and what drives license, data model, hosting and implementation effort.

On this page

Strapi vs Directus vs Payload: which fits which team

Choose Strapi when your team wants a schema-first headless CMS on Node.js with an MIT-licensed Community Edition and a clear upgrade path to paid plans. Choose Directus when you already run a SQL database and want to put an API and admin studio on top of tables you own. Choose Payload when your front end is Next.js and you want the CMS defined in TypeScript code, living inside the same app folder. No platform wins on every factor, so the shortlist should be decided by the questions below rather than by feature lists.

Three deciding factors separate them. First, do you start from a new schema or an existing SQL database? Directus connects to existing databases through the DB_CLIENT setting, while Strapi and Payload model content in their own configuration. Second, is your shop Node.js or Next.js? Strapi runs as its own Node.js service, and Payload installs into a Next.js /app folder, which changes who owns the build and deploy pipeline. Third, how do you weigh licensing? Strapi's Community code under ee/ directories is separately licensed, Payload is MIT licensed, and Directus uses the Monospace Sustainable Core License 1.0, which restricts a Competing Use against Monospace's paid offerings and converts each version to GPL-3.0 four years after release. Have legal review that restriction against your product plans before committing.

Before you decide, confirm the database engines your hosting team already supports, since Strapi 5 and Payload differ on MongoDB, and check which Node.js or Next.js versions your platform team will certify. Build a short proof of concept with your real content model in each shortlisted option and time the first upgrade. The data model, paid features and migration effort in the sections below will then show which trade-off your team can live with.

Which scenario points to which platform

This table matches common team scenarios to the platform that fits best, based on the licenses, databases and tooling covered on this page. Read each row with the final column, which names the condition under which the other option becomes the better choice. No single platform wins every scenario, so start with your database and license constraints, then check your frontend stack.

ScenarioBest fitWhy it fitsOther option wins when
New content model with a non-developer editorial teamDirectusStudio is built for non-technical teammates, and APIs are generated from the database schema.Payload wins when developers want the model defined in code and reviewed alongside the frontend.
Existing PostgreSQL or Oracle database to expose over an APIDirectusConnects to an existing SQL database, and its supported list includes Oracle Database and PostgreSQL.Strapi wins on PostgreSQL if you accept its own schema management. Confirm Directus handles your existing schema first.
TypeScript team already running Next.jsPayloadInstalls into an existing Next.js /app folder and generates TypeScript types from code-defined collections.Strapi wins if the frontend is not Next.js and you want the CMS as a separate Node.js service.
Team that requires MongoDBPayloadPayload supports MongoDB, PostgreSQL and SQLite.Not applicable. Strapi 5 excludes NoSQL databases, and Directus does not list MongoDB among its supported databases.
Team that needs SSO for admin login on a free tierNo clear fit on a free tierStrapi SSO for admin login is a Growth add-on or included in Enterprise, so the free Community plan lacks it.Confirm SSO support and tier placement for Directus and Payload in writing before deciding.
Team that must avoid a competing-use license restrictionPayload or Strapi CommunityPayload is MIT licensed, and Strapi Community code outside ee/ directories is MIT Expat licensed.Directus fits if its license permits your use and you need its Studio and database-first model. Review the Directus license terms with counsel.

Strapi vs Directus vs Payload: what is free and what is paid

Strapi uses two licenses, so the answer to what is free depends on which code you run. Code outside the ee/ directories is provided under the MIT Expat license when you have no Strapi Cloud account, and ee/ directories carry a proprietary Enterprise license. You can read the split in the Strapi LICENSE file.

  • Community edition: Free for self-hosting, with unlimited users, REST and GraphQL APIs, and unlimited entries and API calls.
  • Growth plan: Listed at 45 US dollars per month including 3 users, plus 15 dollars per extra user. SSO is an add-on on this plan, and content history and releases start here.
  • Enterprise plan: Custom pricing. SSO is included, and audit logs and review workflows are Enterprise features.
  • Scope of SSO: Strapi SSO covers administrator login to the admin panel only. End-user authentication is handled by the Users and Permissions plugin, so budget for it separately.

Ask Strapi which of the code in your build falls under the ee/ Enterprise license, and whether your plan or any Strapi Cloud use changes that answer.

Strapi vs Directus vs Payload feature by feature

This table compares the three self-hosted headless CMS options on license, data model, databases, APIs, admin tooling, authentication, runtime and hosting. Read each row as a question to answer for your own stack, and treat cells marked to confirm as open items for the vendor or your proof of concept.

FeatureStrapi 5DirectusPayload
LicenseMIT Expat for Community code outside ee/ directories, proprietary Enterprise license for ee/ directoriesMonospace Sustainable Core License 1.0, which converts each version to GPL-3.0 four years after releaseMIT licensed
Data model approachSchema-first, content types defined in the Strapi projectDatabase-first, generated from an existing or new SQL schemaCode-first, collections and fields defined in TypeScript config
Supported databasesMySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 14 or later, SQLite 3PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server, SQLite, CockroachDB via DB_CLIENTMongoDB, PostgreSQL and SQLite
MongoDB supportNoNoYes
API surfaceREST and GraphQL on all self-hosted plansREST and GraphQL generated from the database schemaConfirm REST and GraphQL endpoint details in the current Payload docs
Admin interfaceStrapi admin panelStudio, aimed at non-technical teammatesCustomizable React admin panel
Built-in authenticationAdministrator login through the admin panel, end-user auth via Users and Permissions pluginConfirm user and role model for your deploymentBuilt-in authentication for admin and customer users
SSO scopeAdministrator login to the admin panel only, SSO is a Growth add-on and included in EnterpriseConfirm SSO support and tier in Directus documentationConfirm SSO options with Payload before scoping
Runtime requirementsActive or Maintenance LTS Node.js versions onlyDocker or Directus Cloud deployment, confirm runtime versionsInstalls into an existing Next.js /app folder, TypeScript
Hosting optionsSelf-hosted, Strapi CloudSelf-hosted with Docker, Directus CloudVercel, Cloudflare Workers with R2 and D1, or self-hosted anywhere

How the data model shapes what you build

The three platforms start from different places, and that choice decides who owns the data model. Strapi is schema-first: you define content types in its admin and in code, and Strapi creates the tables and API from that definition. Directus is database-first: it connects to an existing SQL database through the DB_CLIENT setting and generates REST and GraphQL APIs from the schema it finds. Payload is code-first: collections and fields live in TypeScript inside your Next.js project, and it generates types from that code automatically.

The practical consequence shows up in three places. If you have a legacy SQL database that other systems already write to, Directus is the only one of the three that is designed to sit on top of it as is, so check that your database engine is on its supported list and that your schema can be exposed without restructuring. Strapi and Payload expect the CMS to own its schema, so a legacy import becomes a mapping project, and you should plan for that work before you commit. Migrations also differ: in Strapi, schema changes travel with the project, and upgrades between major versions bring their own data steps, so back up the database first, since the Strapi v4 to v5 documentation says downgrading is not supported.

If your team needs MongoDB, the decision is mostly made for you. Strapi 5 does not support MongoDB or other NoSQL databases, and Directus targets SQL engines only. Payload lists MongoDB among its supported databases, which makes it the option to test first for document-oriented data. Confirm the exact database version and driver support against each vendor's current documentation in your own environment before you design around it, and ask whether your data model depends on features such as multi-document transactions, since those affect how you plan backups and integrity checks.

What drives the running cost of each platform

Running cost for Strapi, Directus and Payload is set less by the license fee than by who operates the runtime, how often you upgrade and how your users are priced. The cards below separate the recurring costs from the one-time ones and name what to request in a quote.

Seat-based Strapi administrator pricing

Strapi's self-hosted Community Edition is free with unlimited users, but the Growth plan is listed at 45 US dollars per month including 3 users, plus 15 dollars per extra user. Cost rises with the number of editors and administrators, not with traffic. Illustrative: a team of 10 administrators on Growth would pay for 7 extra seats each month. Ask the vendor whether seat counts are billed per month and how removed users are handled.

Strapi Cloud as a per-project alternative

Strapi Cloud replaces the server and database work with a per-project subscription listed at 35 US dollars per month for Starter, 90 for Pro and 450 for Business. Each tier carries API request, storage and bandwidth allowances, and Business includes a 99.9% uptime SLA. Compare these fees with the hosting, database and staff time you would otherwise carry. Confirm overage charges and what backups cover before you commit.

Runtime and database operations

Self-hosted Strapi and Payload run on Node.js, and Payload is designed to sit inside a Next.js app, so the application server, process supervision, TLS and the database all become your team's workload. Directus runs against an existing SQL database through DB_CLIENT. Your cloud or data center bill, backup storage, monitoring and on-call coverage recur every month. Ask your hosting partner or internal team to price the database tier, failover and restore testing, not just compute.

Upgrade effort and release cadence

Strapi v4 reached end of life on April 30, 2026, so v4 installations now need a v5 migration, which uses codemods, data migration scripts and a database backup because downgrades are not supported. Strapi 5 minor releases ship roughly weekly, and Payload's v4.0.0 line is still in beta. Budget engineering time for each upgrade window and for regression testing of custom code. Ask each vendor for its support window per major version before you set a maintenance schedule.

License-change risk for Directus

Directus moved from BSL-1.1 in April 2023 to the Monospace Sustainable Core License in 2026, which permits any use except a Competing Use against Monospace's paid offerings. Each version converts to GPL-3.0 four years after release. If your product or service could be seen as competing with Monospace's paid offerings, the legal review and any later re-licensing work becomes a recurring cost. Ask counsel to review the license text against your use case and document the decision.

One-time build versus recurring operation

Schema design, content modeling, access rules, SSO wiring and migration from an existing CMS are largely one-time costs paid to an internal team or implementation partner under a written scope. Hosting, licenses or seats, support retainers and upgrades recur. Payload's code-defined collections push more of the modeling cost into development time, while Strapi and Directus move more of it into an admin interface. Request a quote that separates build fees from recurring run fees, names the hours or days behind each, and states who pays for upgrade testing.

What implementing each platform involves, in order

The sequence below shows the work a team does before a self-hosted Strapi, Directus or Payload site goes live, and the check that closes each stage. Platform-specific differences appear inside each step so the order can be used as a planning checklist.

  1. Confirm license scope and edition

    Before any installation, the team decides which edition it needs and reads the license terms that apply to that edition. For Strapi, the MIT Expat license covers code outside ee/ directories, while ee/ directories carry a proprietary Enterprise license, so SSO, audit logs and review workflows need a plan that includes them. For Directus, the Monospace Sustainable Core License restricts a Competing Use against Monospace's paid offerings, so legal review should test the intended product against that clause. Payload is MIT licensed, so the license review is shortest. The step is done when the owner can name the edition, the features it must include and the license document that governs them, confirmed in writing by legal or procurement.

  2. Select and provision the database

    Each platform uses a different database model, so this decision shapes everything after it. Strapi 5 supports MySQL, MariaDB, PostgreSQL and SQLite, and does not support MongoDB or other NoSQL databases. Directus connects to an existing SQL database and supports PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB through its DB_CLIENT setting. Payload supports MongoDB, PostgreSQL and SQLite, so a team with a MongoDB standard can stay on it only with Payload. The team provisions the database, sets backups and access rules, and records the connection settings. The step is complete when a test connection succeeds from the application host and the database owner has signed off on the choice.

  3. Set up the runtime

    Each platform has its own runtime requirement, and the platform team should confirm it against current vendor documentation before building the host image. Strapi runs only on Active or Maintenance LTS Node.js versions, so the Node.js version must be checked against the Strapi installation documentation before deployment. Directus can be self-hosted with Docker or run on Directus Cloud, so the team chooses a container host or the managed service. Payload installs directly into an existing Next.js /app folder, so the team needs a Next.js build and hosting target, whether that is self-hosted or one of the deployment targets named in the Payload README. The step is complete when the application starts, serves its admin interface and passes a health check in a non-production environment.

  4. Model content and schema

    Content modeling is where the three platforms differ most. Strapi is schema-first, so content types are defined through its admin and project configuration. Directus is database-first, so it generates REST and GraphQL APIs from the existing database schema, which suits teams with a data model already in SQL. Payload is code-first, so collections and fields are written in TypeScript and types are generated from that code, which suits developers who want version control to govern every schema change. The team maps its content types, relationships and localization needs, then builds a representative set in a staging environment. The step is complete when the team has reviewed a sample API response for each content type and confirmed that the model matches the editorial workflow.

  5. Configure roles, permissions and user access

    Access control is set up separately for administrators and end users. In Strapi, administrator roles govern the admin panel, while end-user authentication is handled by the Users and Permissions plugin. Directus enforces role-based permissions on its API, Studio and its native MCP server and AI Assistant, which operate under the same permissions as human users, so those roles must be reviewed before any agent or assistant is enabled. Payload includes built-in authentication, so admin and customer users are managed inside the CMS and field-level access control is defined in code. The team writes the role matrix, tests each role with a non-privileged account and records the results. The step is complete when each role has been tested against the intended read and write actions and the matrix is approved by the data owner.

  6. Configure admin SSO where the edition allows it

    Single sign-on for administrators is an edition question as well as a configuration task. In Strapi's self-hosted plans, SSO is an add-on for Growth and included in Enterprise, and it covers administrator login to the admin panel through an identity provider such as Microsoft Azure Active Directory, with auto-registration, a default role and an optional local login lock-out. Strapi SSO does not govern end-user authentication. The team should confirm with Directus and Payload which admin SSO options are included in its chosen deployment, because this guide does not assert them. The team configures the identity provider, tests sign-in with a standard account and a disabled account, and confirms that the default role assigned on first login is the least-privileged role intended. The step is complete when both test cases behave as designed and the lock-out setting is documented.

  7. Set up backups and the upgrade routine

    Backups and upgrades are recurring work, so the team defines them before go-live. Strapi advises backing up the database before any migration, and its v4 to v5 documentation states that downgrading is not supported, so a restore point is the only rollback. Directus and Payload upgrades should be tested against a copy of production data with the same database engine. The team also sets a release channel for each platform: Strapi 5 minor releases have shipped roughly weekly, Directus 12.5.0 followed 12.4.0 within weeks, and Payload has a v4.0.0 beta line in progress, so the team should choose which channel to follow and how often to test it. The step is complete when a backup restore has been tested and a written upgrade calendar names an owner for each platform.

  8. Document the platform and hand it over

    The last step turns the configuration into a document that an operator, auditor or future team can use. The record should include the chosen license and edition, the database engine and version, the runtime and host, the content model, the role matrix, the SSO settings, the backup and restore procedure and the upgrade calendar. For regulated teams, the document also becomes evidence for internal control reviews, though DeployOpen prepares that evidence and does not issue audit reports or certifications. The team runs a handover session with the operators who will maintain the system. The step is complete when the operators have restored a backup from the document alone and the document has been approved by the platform owner.

Where SSO and login sit in each platform

Strapi's single sign-on applies only to administrator login to the admin panel. You connect an identity provider such as Microsoft Azure Active Directory, and Strapi can auto-register users on first sign-in, assign them a default role, and optionally lock out local email and password login so that only the identity provider can get in. End users of your application are a separate concern. Their authentication runs through the Users and Permissions plugin, so an SSO decision for your editors does not decide how your customers log in. Check the Strapi SSO documentation for the exact provider setup and the default role behavior before you promise editors automatic access. SSO itself is an add-on on the Growth plan and included in Enterprise, so it belongs in the licensing discussion as well as the identity one.

Payload takes a different position. Its built-in authentication manages both admin and customer users inside the CMS, so the same collection model that holds your content also holds the accounts that can log in. That keeps the user store in one codebase and one database, which simplifies backups and access reviews, but it also means your identity team has to decide whether Payload's local accounts are the system of record or whether they must be synchronized from a central directory. Directus handles access through role-based permissions. Those permissions apply equally to its native MCP server and its embedded AI Assistant, so an AI-driven action is limited to what the acting user's role allows. For Directus and Payload, confirm with each vendor, and in your own test environment, whether they support SAML, OpenID Connect or LDAP for administrator login, how new users are provisioned and deprovisioned, whether sessions can be forced to expire, and where audit records of logins and permission changes are kept.

Before choosing, write down three answers for each candidate: who signs in to the admin interface, who signs in to the published application, and who removes access when someone leaves. If the admin interface must follow your central identity policy, Strapi's administrator SSO is a direct fit at the Growth or Enterprise tier. If customer accounts must live in the CMS, Payload's built-in model is the starting point to test. If AI tools will act on content, test that Directus role boundaries hold for those tools before you grant them write access.

Questions buyers ask before choosing a headless CMS

What does licensing cost and effort depend on for Strapi, Directus and Payload?

The license fee depends on which code you run and which features you need, so the answer differs by platform. Strapi's Community Edition is MIT Expat licensed, but code under ee directories falls under a separate Enterprise license, and features such as audit logs and review workflows require the Enterprise plan. Directus is under the Monospace Sustainable Core License, which permits any use except a Competing Use against Monospace's paid offerings, so a commercial product should be checked against that definition. Payload is MIT licensed. Ask each vendor for written confirmation of the terms that apply to your deployment, and ask your counsel to review any Competing Use question before you build a commercial product on Directus.

How long does a headless CMS rollout take?

No duration is given here because the timeline depends on the scope. The main drivers are the number of content types, the migration of any existing content, the number of editor roles and approval steps, identity integration for administrators, the hosting design, and testing of the public API against your front ends. A written scope with defined deliverables is the basis for any timeline. Ask any implementation partner to state the assumptions behind its timeline, including what your team must provide and when.

What skills does our internal team need to run these platforms?

The skills differ by platform. Strapi 5 runs on Active or Maintenance LTS Node.js versions and needs a database administrator for MySQL, MariaDB, PostgreSQL or SQLite. Directus connects to an existing SQL database, so database administration and schema change control matter most, and Studio helps non-technical teammates. Payload installs into a Next.js app and generates TypeScript types from code-defined collections, so Next.js and TypeScript skills are required. For administrator login through an identity provider, Strapi SSO applies to the admin panel, so someone must configure the provider, roles and the local login lock-out setting. Confirm these needs against your own staff before you commit.

Can our team deploy and maintain a headless CMS without outside help?

A team with the skills listed above can usually deploy a self-hosted headless CMS in-house, but the answer depends on the workload. Work that tends to need experienced help includes hardening the hosting stack, configuring identity integration, designing backup and restore, planning upgrades, and writing the operating documentation that an auditor will ask to see. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure under a fixed scope agreed in writing, and offers retainers for ongoing support. Compare that with the cost of your own staff time before deciding.

How do Strapi v4 to v5 upgrades work, and can we roll back?

Strapi provides an upgrade tool with codemods, data migration scripts that run on the first start of Strapi 5, and a breaking changes list. Strapi v4 reached end of life on April 30, 2026, so existing v4 sites should plan a move. The Document Service API replaces the Entity Service API and the response format changes, and a Strapi-Response-Format: v4 header can help during migration. Back up the database before you start, because the documentation says downgrading is not supported. Test your front ends against the new response format in a staging copy first.

What does the Payload v4 beta mean for production plans?

A beta line is not a stable release, so production plans should pin a released version rather than build on a beta. Payload v3.91.0 was released on October 15, 2026, and v4.0.0-beta.2 was published on October 16, 2026. Treat the v4 beta as a reason to plan a later upgrade and to read the release notes, not as a base for launch. Ask the vendor about its support and upgrade policy for the version you choose, and schedule a test upgrade in a non-production environment before any v4 adoption decision.

How does the Directus license change affect a commercial product?

Directus moved from BSL-1.1, adopted in April 2023, to the Monospace Sustainable Core License in 2026. The new license permits any use except a Competing Use against Monospace's paid offerings, and each version converts to GPL-3.0 four years after release. A commercial product that embeds Directus as a backend is not automatically a Competing Use, but the boundary depends on what the product does and how it relates to Monospace's offerings. Get a written legal review of the specific product before you commit, and record the license version you deploy so that future changes can be tracked.

Which database and hosting factors should we check before choosing?

Start with the database your organization already runs and supports. Strapi 5 supports MySQL, MariaDB, PostgreSQL and SQLite and does not support MongoDB or other NoSQL databases. Directus supports PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB through its DB_CLIENT setting. Payload supports MongoDB, PostgreSQL and SQLite. Hosting is also a driver: Directus can run in Docker or on Directus Cloud, and Payload can run on Vercel, Cloudflare Workers with R2 and D1, or anywhere you self-host. Confirm version support for your chosen database against each vendor's current documentation.

How DeployOpen helps choose and implement a headless CMS

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Strapi, Directus or Payload decision, that means starting from your content model, database standard and licensing position before any build begins.

How we scope

  • Written scope lists which candidate CMS is in play, the content types, editors and locales it must serve.
  • Scope records your database standard, such as PostgreSQL, MySQL, MariaDB or MongoDB, and the Node.js version policy.
  • Licensing review covers Strapi Enterprise features, the Monospace license terms for Directus and Payload's MIT model.

How we build

  • Schema work follows the chosen model: schema-first in Strapi, database-first in Directus, or code-first collections in Payload.
  • Authentication design separates administrator login from end-user accounts, since Strapi SSO covers only the admin panel.
  • Security testing of APIs, permissions and hosting configuration runs before content teams receive access.

How we hand over

  • Deliverables include deployment documentation, environment configuration notes and the permission and role model.
  • Backup and restore procedures are documented and tested, including the database backup step before any version upgrade.
  • Handover covers how to add content types, run upgrades and confirm which features your plan actually includes.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers after handover.
  • Upgrade planning tracks each vendor's release and end-of-life dates, so your team knows which version to target.
  • Support scope is agreed in writing, and any quote follows from that written scope rather than a published price list.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.