How to use this headless CMS requirements checklist
Your team needs a headless CMS that editors can work in, that feeds more than one front end, and that you can host where your data rules allow. This checklist turns those needs into tests you can run against Strapi, Payload and Directus, so the shortlist rests on evidence from a trial instance rather than on vendor claims. Each requirement should end in a yes, no or conditional answer that a named person can verify.
Rank requirements by who depends on them. Editor needs such as preview, locale handling and review steps usually decide daily satisfaction, developer needs such as the content model format, REST or GraphQL access and the database engine decide how fast you can ship, and security and compliance needs such as admin SSO, audit logs and access control decide whether the platform can be approved. Before you shortlist, read the license and paid-edition terms for each product. Strapi separates its Community code from Enterprise directories, Directus uses its own license, and several features that matter to security and compliance sit in paid tiers, so a feature that looks free may not be.
Treat this checklist as a starting point, not a substitute for a written scope. The answers depend on your identity provider, hosting location, traffic, content volume and the front ends you will build, and none of those are settled by a generic list. Use the results to write the scope with your implementation partner, including which tests run in a pilot, who signs off each result and what evidence is kept for your own records.
Functional requirements every headless CMS shortlist should test
This table lists the functional requirements that separate headless CMS candidates in practice, with the editor and developer reason behind each one and a way to test it with a sample content model. Use it to build a proof of concept scorecard, and note where a feature depends on a paid edition before you compare license costs.
| Requirement | Why it matters | How to verify in a proof of concept |
|---|---|---|
| Content modeling (collections, components, relations) | Editors need reusable blocks and linked entries, and developers need a schema that stays maintainable as the site grows. | Build a sample model with a reusable component, a one-to-many relation and a nested block, then add a field and confirm existing entries migrate cleanly. |
| Versions and drafts | Editors must change live content without publishing unfinished work, and teams need to roll back a bad edit. | Create a draft, publish a new version, revert to an earlier one and confirm the API returns only the published state to the public front end. |
| Locales and fallback rules | Multilingual sites need translated fields, fallback to a default language and clear per-locale status. | Model two locales with one untranslated field, confirm fallback behavior in the API and check how URL slugs are stored per locale. |
| Editorial roles and approval workflows | Regulated and multi-team publishers need separation between authors, reviewers and publishers, plus a record of who approved what. | Define three roles with different permissions, route a draft through a review stage and confirm which steps need a paid edition (review workflows are an Enterprise feature in Strapi's self-hosted plans). |
| Live preview of unpublished content | Editors need to see unpublished changes in the real front end before release, which cuts publishing errors. | Connect a preview URL to a draft entry in a test front end and confirm the preview is limited to authorized editors. |
| REST and GraphQL API coverage | Front ends, apps and partners consume content in different ways, and query shape affects performance and caching. | Query the same entry with REST and GraphQL, filter by locale and relation depth, and measure response shape against the front end's needs. |
| Media library and image transformation | Images drive page weight and accessibility, so editors need alt text fields and developers need resized, cached assets. | Upload a set of images, confirm alt text and metadata fields, request resized variants and check whether transformations run in your infrastructure or a third-party service. |
| Admin panel customization | Editors work in the admin panel daily, and custom views for review queues or field help reduce training time. | Add a custom field component and a filtered list view, then confirm the change survives an upgrade in a staging environment. |
Which license and edition terms change what you can build
Strapi's Community Edition is MIT licensed, so the code outside the ee/ directories can be used, modified and self-hosted without a per-seat license fee. The paid tier is separate: code under ee/ directories falls under the Strapi Enterprise Edition license, and features such as audit logs and review workflows sit in that edition. The latest release in the supplied facts is v5.58.0, published on October 14, 2026, and Strapi 5 minor releases ship roughly weekly, so plan a regular upgrade cadence. Strapi v4 reached end of life on April 30, 2026, so any project still on v4 needs a migration plan.
- Community code: MIT applies to code outside ee/ directories, which covers the core content model, REST and GraphQL APIs and self-hosting.
- Enterprise code: Audit logs and review workflows are Enterprise features, so confirm which paid edition your approval process requires.
- Admin SSO: SSO for the admin panel is an add-on on the Growth plan and included in Enterprise, so budget for it if editors must sign in through your identity provider.
- Version currency: v4 reached end of life on April 30, 2026, so a new build should start on v5.
- Hosting terms: Strapi Cloud is a separate commercial service, so a self-hosted build does not depend on it.
Have counsel confirm that the Community license and any Enterprise components fit your internal use and the professional services your implementation partner will provide.
Payload is MIT licensed, and it is built as a Next.js framework that installs directly into an existing Next.js /app folder. That means the CMS is part of your application codebase, so the license applies to code your team owns and deploys, and no separate CMS server is required in the usual sense. The supplied facts list v3.91.0 as released on October 15, 2026, and a v4.0.0 beta line is in progress, with v4.0.0-beta.2 published on October 16, 2026. Plan for that transition before you commit to a long-lived production build.
- MIT terms: The framework is MIT licensed, which generally permits internal use, modification and commercial services built on it, subject to the license text.
- Beta line: The v4.0.0 beta is in progress, so pin versions and test upgrades before moving to a major release.
- Code ownership: Schema, access rules and admin customizations live in your repository, which simplifies reviews but shifts upgrade work to your team.
- Hosting options: Payload can deploy to Vercel, to Cloudflare Workers with R2 and D1, or be self-hosted, and the hosting choice does not change the license.
- Built-in authentication: Admin and customer users are managed in the CMS itself, so confirm whether your identity requirements need external SSO.
Confirm with counsel that MIT terms cover your planned use, and ask your implementation partner how paid services, third-party plugins and any commercial components will be licensed.
Directus is licensed under the Monospace Sustainable Core License 1.0 (MSCL-1.0-GPL), which is not an OSI-style permissive license. The license permits use for any purpose other than a competing use, and it explicitly includes internal use and professional services to deploy or host Directus for a licensee. Each version converts to GPL-3.0 four years after release. The supplied facts list v12.5.0 as released on October 7, 2026, after v12.4.0 on September 22, 2026. Directus also changed its license from BSL-1.1 in April 2023 to the current terms in 2026, so older forks and documents may describe different terms.
- Competing use: The restriction targets competing use against Monospace's paid offerings, so define what your organization and any partner will do with the code.
- Internal and services use: The license explicitly covers internal use and professional services that deploy or host Directus for a licensee.
- Conversion date: Each version converts to GPL-3.0 four years after release, so the terms for an older release differ from a newer one.
- License history: The change from BSL-1.1 in April 2023 means third-party guides may cite outdated terms.
- Managed option: Directus Cloud is a separate managed service, so self-hosting with Docker keeps hosting under your control.
Have counsel review the MSCL-1.0-GPL text against your intended use and the services your partner will provide, and record the Directus version you deploy.
Security requirements editors and auditors will ask about
Auditors and security teams rarely accept a CMS on feature lists alone. They ask who can sign in, what each role can change, who approved what, and how secrets, data and runtimes are kept current. The cards below cover the items that most often change the edition, the build effort or the hosting choice.
Admin SSO through an identity provider
Editors and administrators should sign in with the corporate identity provider so access follows joiner, mover and leaver processes. Check whether SSO covers only the admin panel or also end-user accounts, because these are separate concerns. In Strapi, SSO covers administrator login only, while end-user authentication is handled by the Users and Permissions plugin. In Strapi's self-hosted plans, SSO is an add-on for Growth and included in Enterprise. Confirm the same split for Payload and Directus with the vendor and your identity provider.
Field-level and role-based access control
Roles decide which content types, locales and fields each editor, reviewer or integration can read and write. Field-level rules matter when legal, pricing or personal data sits beside marketing copy in the same entry. Payload offers field-level access control in its built-in feature set, and Directus applies role-based permissions to its API, Studio and MCP server alike. Test each role with real accounts before launch, and confirm with the vendor whether a given rule needs a paid tier or custom code in your version.
Audit logs of changes and approvals
An audit trail should record who created, changed, published or approved each entry, and when. Auditors also ask whether logs are tamper-evident, how long they are kept and whether they reach your SIEM. In Strapi's self-hosted plans, audit logs and review workflows are Enterprise features, so a community deployment needs a custom logging design or a paid edition. Ask each vendor for the exact events logged, the retention you control, and whether approval steps are recorded or only the final state.
Secrets and environment handling
Database credentials, API tokens, SSO client secrets and signing keys should live in a secrets manager or the platform's secret store, not in source control or shared files. Separate environments so that preview and staging cannot reach production data. Check how each CMS reads its configuration, how keys rotate without downtime, and who can read the production environment. Your platform team should own this design, and the review should include the build pipeline that deploys content types and plugins.
Database encryption and backup
Content, user accounts and media references all sit in the database, so encryption at rest and tested restores are core evidence. Strapi 5 supports PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later and SQLite 3, and does not support MongoDB. Payload supports MongoDB, PostgreSQL and SQLite, and Directus connects to several SQL engines through its database client setting. Confirm encryption at rest and backup capabilities with your hosting provider and database vendor, and schedule restore tests, not just backup jobs.
Patching cadence for CMS and runtime
The CMS, its Node.js runtime and its database each receive security fixes on their own schedule, and an unpatched runtime is often the finding auditors record. Strapi 5 runs only on Active or Maintenance LTS Node.js versions, and Strapi v4 reached end of life on April 30, 2026. Ask each vendor for its support window and release notes, decide who applies patches and how fast, and record that decision as a control. Plan for major version upgrades as projects, not routine patches.
How to verify a headless CMS against these requirements
This time-boxed proof of concept turns the checklist into evidence. Run it on the same content and roles against each candidate, and record what passed, what needed a workaround and what needs a paid edition or a vendor answer.
Model two real content types
Your content architect builds two content types from your actual pages or records, including at least one reusable component (for example, a call-to-action block or a repeatable FAQ item) and a field that varies by locale. Work from your existing content, not a demo schema. The step is done when both types exist in each candidate, you can add a nested component, and you can enter the same record in two locales. Keep screenshots of the schema definitions and the locale settings, and note any field you had to model differently to fit the product.
Configure two roles with different permissions
An administrator creates one editor role limited to a single section or locale and one reviewer or publisher role with approval rights. Test each role by signing in and attempting actions it should not have, such as publishing outside its scope or changing the content model. The step is done when every attempt matches your permission matrix. Record the role definitions, the test accounts used and the outcome of each attempt. Confirm with the vendor whether the role model you need is in the community edition or only in a paid plan.
Publish a draft into a preview build
An editor creates a draft of one of the two content types, then opens it in the preview experience connected to a test front end. A second user then publishes it and the change appears on the live build after the front end refreshes. The step is done when the preview shows unpublished content only to authorized users and the published version matches the preview. Save the preview URL configuration, timestamps and before and after captures, and note whether preview requires custom code on your side.
Trigger a webhook to a test front end
Configure a webhook on publish and unpublish events that calls a test endpoint, such as a simple receiver or a staging front end that revalidates a cache. Publish a change and confirm the receiver gets the payload and the front end updates within your target window. The step is done when the delivery log shows success and a failed endpoint produces a visible error. Keep the webhook configuration, sample payloads and delivery logs, and record whether retries and signing are built in or need to be added.
Check audit and history output in the edition under consideration
Using the edition you intend to buy or run, review who created, edited, published and deleted each test entry, then restore an earlier version. Check whether the audit trail records the user, the time and the change, and whether it can be exported for a compliance file. The step is done when you can answer who approved a specific version from the logs alone. Record which features worked only on the paid tier, and confirm in writing with the vendor whether audit logs and review workflows are included in the plan you are pricing.
Run a backup and restore
Your platform engineer takes a database and media backup of the test instance, makes further changes, then restores to a clean environment from the backup. Verify that content, content types, users, roles and uploaded media all return and that the restored instance starts with the same version. The step is done when the restored copy matches the source on your test checks. Record the backup method, the restore steps, the time taken and any items that needed manual handling. Confirm the supported database versions and the rollback path before any upgrade.
Record the result for each requirement
Your compliance lead and architect score each requirement from the checklist as passed, passed with a workaround, requires a paid edition, or not supported, with the evidence file name next to it. Include the license terms for the candidate so the scoring reflects both function and permitted use. The step is done when every checklist line has a result and an owner. The output is a signed scorecard that goes into the shortlist decision and the written scope for any implementation partner.
Operational requirements: hosting, upgrades, backup and support
This table compares what each self-hosted headless CMS asks of your runtime, upgrade path, backups and on-call ownership. Read each row as a question to put to your partner and to your own environment before you choose a product. The main takeaway is that a major version move, especially Strapi 4 to 5, and restore testing are the operational events most likely to cause downtime if they are not rehearsed.
| Requirement | What to confirm or verify | Where it usually fails |
|---|---|---|
| Node.js runtime | Strapi 5 runs only on Active or Maintenance LTS Node.js versions. Confirm the chosen LTS line in your build pipeline and container images before go-live. | Hosts pinned to an end-of-life Node.js version after a platform image update |
| Database engine | Strapi 5 supports PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later and SQLite 3, and does not support MongoDB. Directus supports several SQL engines through DB_CLIENT. Payload supports MongoDB, PostgreSQL and SQLite. | Database version drift between staging and production, or a database engine the platform does not support |
| Hosting model | Payload is a Next.js app that can deploy to Vercel, Cloudflare Workers with R2 and D1, or self-hosted infrastructure. Directus runs with Docker or on Directus Cloud. Confirm where the database, media storage and backups sit in your own environment. | Hosting decisions made before data residency and backup locations are documented |
| Major version upgrades | Strapi v4 reached end of life on April 30, 2026, so v4 installs need a planned move to v5. Strapi's upgrade tool and codemods help, but the docs say to back up the database first because downgrading is not supported. Ask for a written rollback plan. | Teams start a v4 to v5 move without a dry run, then discover custom code relies on the Entity Service API |
| Dry-run upgrade | Run each upgrade against a restored copy of production content and media, record the migration output, time the run, and check API responses and editor workflows. Confirm the outcome with the partner before any production change. | Staging uses a seeded sample instead of production-shaped data, so migration errors appear only in production |
| Backup and restore testing | Confirm that database and media backups are taken on a schedule, that restores are tested on a separate environment, and that the team knows the recovery steps. Ask who approves a restore and where the restore evidence is kept. | Backups exist but restores have never been run, or media files are missing from the backup set |
| Staging and release process | Keep a staging environment that matches production in CMS version, plugins, database engine and environment variables. Confirm how content model changes move from staging to production, since schema changes can break front ends. | Schema changes are edited directly in production, or staging diverges after urgent fixes |
| Monitoring and alerting | Monitor API availability and latency, database health, storage capacity, failed scheduled publishes and webhook delivery to the front end. Confirm which alerts page a person and which go to a ticket queue. | Only uptime is monitored, so failed publishes or broken preview links go unnoticed until an editor reports them |
| On-call and support ownership | Name the owner for CMS incidents, the owner for the front end and the owner for the hosting layer. Confirm response expectations in the written scope or support retainer, since these are agreed per engagement rather than set by the software license. | Responsibility splits between the internal team, the agency and the hosting provider, and no one owns the first response |
Questions buyers ask before choosing a headless CMS
How much does a self-hosted headless CMS cost to run?
The software license is the smallest part of the bill for most Strapi projects, because the Community Edition is free to use. What you pay for is the edition you need, hosting, content modeling, frontend build and ongoing support. Strapi's self-hosted pricing page lists Growth at 45 US dollars per month including 3 users, plus 15 dollars per extra user, and Enterprise at custom pricing. Strapi Cloud lists Starter at 35 US dollars per month per project, Pro at 90 and Business at 450. Those are list prices from the vendor and change over time, so confirm them on the pricing pages before you build a budget. Payload and Directus are also open source, but their paid hosting and support options follow their own terms. Ask any implementation partner for a fixed-scope quote that separates one-time build work from recurring hosting, upgrades and support.
How long does a headless CMS proof of concept and rollout take?
Duration depends mainly on how many content types you have, how many locales and sites sit on the platform, how many systems must connect, and how much content migrates from an existing CMS. A proof of concept usually tests one or two real content types, one editor workflow, preview and one front end, which keeps the scope narrow. A full rollout adds identity integration, roles, hosting controls, backup and restore testing, editor training and cutover. No duration is set in this guide, so ask a partner to tie each phase to written deliverables and acceptance criteria before work starts. Major version changes, such as moving from Strapi 4 to 5, can add time because the API response format and data layer change.
What does the client need to provide for a headless CMS project?
A headless CMS project needs named people who can make decisions, not only a technical contact. Assign an owner for content and editorial workflow, an owner for identity and single sign-on, an owner for hosting and infrastructure, and an owner for approvals on regulated or legal content. Each owner should confirm the content model, the roles and the publishing rules in writing. Without these decisions, the build slows down at the points where editors need to sign off, and the rework is usually expensive. Your identity owner also needs to confirm which identity provider editors will use and whether admin login must be enforced through it.
Can an internal team build and run a headless CMS alone?
Yes, a capable internal team can run a headless CMS without a partner, particularly if it already operates Node.js applications and databases. The harder work is ongoing: keeping the platform patched, testing backups, managing access, supporting editors and planning major upgrades. Check that your team has skills in database administration, identity integration, frontend delivery and security testing, and that it has time for upgrades after the launch. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, under fixed-scope agreements or retainers. Many organizations split the work, keeping content operations internal and bringing in outside help for the build and the upgrades.
How do I choose between Strapi, Payload and Directus?
Start with your team and your data, not with the feature list. Strapi is a Node.js headless CMS with a mature admin panel, and its Community Edition is MIT licensed, though SSO and audit logs sit in paid editions. Payload is a Next.js framework that installs into an existing Next.js app, supports MongoDB, PostgreSQL and SQLite, and generates TypeScript types from code-defined collections. Directus connects to an existing SQL database and generates REST and GraphQL APIs from the schema, and it is licensed under the Monospace Sustainable Core License, so read its terms against your use case. Test each shortlisted platform with one real content model, your identity provider and your hosting setup before you decide. Confirm version support, database support and license terms directly from the project sources.
Do SSO and audit logs require a paid plan?
In Strapi's self-hosted plans, SSO is an add-on for Growth and included in Enterprise, and audit logs and review workflows are Enterprise features, according to Strapi's self-hosted pricing page. Strapi SSO covers administrator login to the admin panel, so end-user authentication is handled separately by the Users and Permissions plugin. Payload includes built-in authentication for admin and customer users, and Directus includes role-based permissions, but you should confirm what each platform provides in your chosen version before you assume a feature is available. Where compliance or content approval depends on audit history, ask the partner to show the evidence each platform produces and to state which edition or extension supplies it.
What should I ask a partner before signing a headless CMS quote?
Ask for a written scope that lists each content type, locale, site, editor role, workflow and integration in the build. Ask which edition or license each feature needs, who pays for it and whether it recurs. Ask how preview works for editors, how backups are tested, how the platform will be upgraded and how long support covers each version. Ask how content will be migrated and how the team will verify it. Finally, ask what the partner will hand over at the end, including documentation, runbooks and access records, so your team can operate the platform after the engagement closes.
Which questions separate Strapi, Payload and Directus in a shortlist
The differences between Strapi, Payload and Directus show up in a few questions, and a shortlist should be scored on them before feature lists are compared. The first is who builds the content model and how it changes. In Payload, collections and fields are defined in code, so developers own the schema, and Payload generates TypeScript types from it. In Strapi, content types are defined in the schema and the admin panel, with changes tracked through the project. In Directus, the schema is read from an existing SQL database or edited in Studio, so the database and the admin interface carry more of the modeling decisions. Ask each vendor or partner which team will make model changes after launch, and who reviews them, because that answer determines the change process more than any feature table. The second question is how editors preview unpublished content, and which settings sit behind it. Payload includes live preview and versions and drafts in its built-in feature set. Strapi's content history and releases start at the Growth plan of its self-hosted pricing, and the Enterprise plan adds review workflows and audit logs. Directus supports editing through Studio and its role-based permissions. Confirm for each candidate how preview URLs are generated for your front end, which roles can see drafts, and whether scheduled or staged publishing needs a paid tier. Third, check which features sit in paid editions, and which license terms apply to internal use and to partners. Strapi's Community Edition is MIT licensed, but SSO for administrators is an add-on on Growth, while audit logs and review workflows are Enterprise features. Directus is licensed under the Monospace Sustainable Core License 1.0, which permits internal use and professional services to deploy or host the software for a licensee, but excludes a competing use. Payload is MIT licensed. Have legal and procurement review the license file for each product, and confirm in writing whether your implementation partner's work, including hosting and customization, falls within the permitted uses. Major upgrades should be part of the same review: Strapi 4 reached end of life on April 30, 2026, so ask each candidate how it handles version moves and what the rollback path is.
What each team must confirm before signing off
Sign-off works best when each function owns a different part of the checklist and expects a different kind of evidence. Content owners confirm the content model and editorial behavior: sample entries for each content type, locale settings, the roles that can create, review and publish, and a preview test on a draft that has not been published. Developers confirm the API contract and the front-end integration: the REST or GraphQL endpoints, the response format the front end expects, and the results of API tests that cover published versus draft reads. For Strapi, that also means confirming which major version and Node.js line the project runs on, since the installation requirements in the supplied documentation are version-specific. Ask for the test output itself, not a verbal confirmation.
Security and compliance leads sign off on identity, access and recoverability. They should expect an access review record listing every administrator and editor account, the role each holds, how administrator login is federated, and whether local login is still permitted. They should also confirm which features the chosen edition provides. In Strapi's self-hosted plans, SSO and audit logs sit in paid tiers, so the sign-off record should name the edition and plan that the organization is actually buying, not the one used in the proof of concept. Audit log exports should show who changed or published what, and a backup restore test should show that the database and media storage can be rebuilt into a working environment. DeployOpen prepares these controls and evidence for compliance assessments, but independent auditors issue any audit report, so the organization should agree in advance which evidence its auditor will accept.
How DeployOpen scopes, delivers and supports a headless CMS selection
DeployOpen turns a headless CMS requirements list into a written scope that compares Strapi, Payload and Directus against your content model, editor roles, locales, preview and identity needs. We then plan and deploy the chosen platform inside your own infrastructure, and document and support it after handover.
How we scope
- Engagements are fixed-scope, with requirements, deliverables and timelines agreed in writing before work starts
- Requirements workshop covering content types, locales, editor roles, approval steps and preview needs
- Written check of which features each product needs from a paid edition, such as SSO, audit logs and review workflows
- Confirmation of database, Node.js version and hosting constraints for your own cloud, data center or air-gapped network
How we build
- Content model prototype in the shortlisted platform, tested against your sample entries, locales and media types
- Role and permission matrix configured for editors, reviewers, publishers and API consumers
- Preview and API access tested with the front ends that will consume the content, including caching behavior
- Security testing of the CMS and its APIs before go-live, with findings tracked to closure
How we hand over
- Deployment, configuration and content model documentation delivered to your platform and editorial teams
- Backup and restore procedure for the database and media store, tested before handover
- Runbooks for upgrades, including the migration steps for major versions and the backup required before any change
- Compliance evidence packaged for your auditors, such as access control settings and change records, without issuing any attestation
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover
- Monitoring and patching of the CMS, database and hosting layer against the vendor's supported release lines
- Periodic review of licence terms and paid edition features as your editorial and integration needs change
- Scheduled reassessment of the content model when new brands, locales or channels are added
