What a headless CMS costs, and what it depends on
A self-hosted headless CMS has no license fee for the core software. Strapi's Community Edition is MIT licensed outside its ee directories, Payload is MIT licensed, and Directus is available under the Monospace Sustainable Core License 1.0, which permits internal use and professional services to deploy or host it. The total cost of ownership depends on paid edition features, hosting, content model complexity, the frontend build and the size of your team. Per-seat SaaS CMS pricing scales with the number of editors and content volume, while self-hosting moves the cost into infrastructure, licensed add-ons and people who build and run the system.
The one-time costs are the content model design, the migration of existing content, the frontend build and the integration with identity and other systems. The recurring costs are hosting, database and media storage, backups, upgrades, monitoring and the staff or partner time to keep the platform current. Strapi shows how a paid edition can change the bill: in its self-hosted pricing, SSO is an add-on for the Growth plan and included in Enterprise, while audit logs and review workflows are Enterprise features. Confirm which of these you need before you compare totals, because they are the features most often bought later.
Ask any partner or vendor for a quote that separates these lines: licensed edition features by name, hosting environments (staging and production), database and media storage sizing, content model and migration hours, frontend build, upgrade and support terms, and who holds the operational runbooks. For a SaaS comparison, price the editor seats you will need in three years, the content volume limits and the SSO and audit features on the plan you would actually buy. Sanity's public pricing, for example, lists per-seat plans with SSO and audit trail only on its custom-priced Enterprise tier, so the comparison should use that tier for regulated teams.
Which costs sit in-house, with a partner and in SaaS
This table compares who pays for each cost component under a self-hosted build, a partner-led implementation and a per-seat SaaS CMS. Read each row as a question to answer in a quote: which costs are one-time, which recur, and which party carries them. The main takeaway is that self-hosted software removes per-seat fees but moves licensing, hosting, upgrades and support onto your budget or your partner's scope.
| Cost component | Self-hosted build (in-house team) | Partner-led self-hosted | Per-seat SaaS CMS |
|---|---|---|---|
| Software license | Community editions are free to use under MIT (Strapi Community, Payload) or the Directus license. Paid Strapi Enterprise is a separate license, recurring if chosen. | Same license terms as the build column. The partner's fee covers planning and setup, not the software. | Included in subscription. Sanity Growth is listed at 15 US dollars per seat per month, recurring. |
| Hosting and infrastructure | Recurring cloud or data center costs paid by you. Strapi Cloud Starter, Pro and Business are listed at 35, 90 and 450 US dollars per month per project. | Recurring infrastructure paid by you, usually at your cloud account. Partner fee for setup, hardening and backups is one-time or retainer. | Included in subscription. Data residency and backup options usually sit in higher tiers, so confirm them with the vendor. |
| Paid edition features (SSO, audit logs, workflows) | Strapi Growth is listed at 45 US dollars per month including 3 users. SSO is an add-on at Growth, and audit logs and review workflows are Enterprise features. | Same edition costs as the build column. Ask the partner which features your scope needs before quoting. | Often bundled in enterprise tiers. Sanity Enterprise includes SSO, audit trail and backups, priced on request. |
| Content modeling | One-time effort by your team, plus ongoing changes as content grows. | One-time design fee in the written scope, with change requests priced separately. | Mostly one-time setup, often done in the vendor's studio tools. Changes after launch are still staff time. |
| Frontend build | Your developers build and maintain the website or app that reads the CMS API. Recurring as sites change. | Partner builds the frontend under a fixed scope, then supports it under a retainer if you choose. | Same frontend cost as the other models. The CMS does not remove it. |
| Integrations and migration | One-time work for identity, search, CDN and data imports, owned by your team. | One-time integration and migration work in the fixed scope. Ongoing changes may need a retainer. | Connectors and migration tools vary by vendor. Confirm which integrations are included and which are custom. |
| Upgrades and support | Recurring. Your team applies security and major version upgrades. For example, Strapi v4 reached end of life on April 30, 2026. | Recurring retainer for upgrades, testing and support, if you contract it. Otherwise your team carries it. | Vendor applies platform upgrades. Your team still handles content model changes and frontend compatibility. |
| Seat or user growth | No per-seat fee on Strapi Community. Growth adds 15 US dollars per extra user above 3 users. | Seat costs follow the chosen edition, not the partner. | Recurring and scales with editors. Sanity Growth is listed at 15 US dollars per seat per month, up to 50 seats. |
What the open-source license and paid editions cover
Strapi splits its code by directory. Code outside the ee/ directories is the Community Edition under the MIT Expat license, and it is free to run. Code under ee/ carries a separate Strapi Enterprise license. The self-hosted pricing page lists a Growth plan at 45 US dollars per month including 3 users, with 15 dollars per extra user, and an Enterprise plan at custom pricing. Both paid plans include REST and GraphQL APIs and unlimited entries and API calls.
- Community Edition: free, unlimited users, REST and GraphQL APIs, and content modeling.
- Growth plan: adds content history and releases, and SSO is available as an add-on.
- Enterprise plan: includes SSO, audit logs and review workflows.
- Per-user cost: Growth charges per extra user beyond the included seats, so user counts drive the recurring fee.
- Admin SSO scope: Strapi SSO covers administrator login to the admin panel only. End-user authentication is handled by the Users and Permissions plugin.
Confirm with Strapi which edition contains each feature your editors need, and whether the Enterprise license terms affect your hosting or contractor arrangements before you commit to a plan.
Payload is licensed under MIT, and its framework and CMS features are not split into a paid tier in the way Strapi's are. Payload installs directly into an existing Next.js /app folder, so the license cost is zero and the recurring cost sits in hosting, developer time and any commercial services you buy. Built-in authentication, versions and drafts, localization, field-level access control, and a customizable React admin panel are part of the open-source package.
- No license tier: MIT permits internal use, modification and redistribution without a per-seat fee.
- Built-in access control: field-level permissions and user management live in the CMS itself.
- Built-in user management: admin and customer users can be managed without a separate identity layer, which reduces one integration cost.
- Enterprise identity: confirm whether your identity provider requirements need custom work, because SSO for admin users is not a packaged paid feature in the same way as Strapi's.
- Version track: v3.91.0 is the released line, and a v4.0.0 beta is in progress, so plan upgrade effort against the release you choose.
Check that your audit, review and history requirements can be met through code and the chosen database, and price that build work into your quote.
Directus is licensed under the Monospace Sustainable Core License 1.0 (MSCL-1.0-GPL). It permits any use except a Competing Use against Monospace's paid offerings. The license file explicitly covers internal use and professional services to deploy or host Directus for a licensee. Each version converts to GPL-3.0 four years after release, according to the license page. Directus can run on your own Docker environment or on Directus Cloud, the managed service.
- Internal use: explicitly permitted under the license file.
- Partner-delivered hosting: the license file names professional services to deploy or host for a licensee as a permitted use, so an implementation partner can run it for you.
- Competing use: offering Directus as a competing hosted product is restricted, which matters if you are a software vendor.
- License history: the project moved from BSL-1.1 in April 2023 to MSCL in 2026, so review terms for the specific version you deploy.
- Cloud option: Directus Cloud is a separate recurring service that you can compare with self-hosting.
Have counsel confirm the license against your intended use, including any contractor, subsidiary or redistribution scenario, before you sign.
License fees are only one line in the total cost. Paid editions charge recurring subscriptions, while the open-source core is free to run. The rest of the cost falls on hosting, implementation, content modeling, frontend build, upgrades and support. These costs recur or appear at different points depending on which edition and license you choose.
- Recurring license fees: Strapi Growth and Enterprise, and any Directus Cloud or Strapi Cloud subscription, recur monthly or annually.
- Hosting: self-hosted environments carry infrastructure and operations costs, while managed hosting bundles these into the plan.
- One-time build: content modeling, frontend integration, SSO configuration and migration are usually one-time, though upgrades recur.
- Upgrade effort: Strapi v4 reached end of life on April 30, 2026, which shows that major version changes carry real migration cost.
- Seat growth: per-user pricing on Strapi Growth grows with editors and admins, so model headcount over the contract period.
Ask any implementation partner to separate license, hosting, build and support costs in the quote so you can see which lines change if you move between editions.
The right edition depends on how your organization will use the CMS and who will run it. Before comparing vendor quotes, confirm the license terms and the feature list against your requirements. Write down which features are mandatory, such as SSO for editors, audit history or approval steps, and which are optional. Then check the license and edition for each candidate.
- Feature list: map admin SSO, audit logs, review workflows and content history to the edition that includes them.
- Usage scope: confirm whether internal use, contractor hosting and affiliate use are covered by the license.
- Redistribution: confirm whether you will ship the CMS to customers, partners or other entities.
- Edition change path: ask what happens to data, configuration and fees if you move from Community to a paid tier later.
- Support obligations: confirm who provides security patches and upgrades for the edition you choose.
Record the answers in writing so the implementation partner's scope and your procurement file match the license terms.
What moves the headless CMS cost up or down
Headless CMS cost is driven by who edits content, which features those editors need, and how much the frontend and hosting must do. The six drivers below connect the license decision to the labor, infrastructure and migration work that usually matters most in a quote.
Number of editors and seats
Per-seat SaaS pricing scales with every editor, reviewer and contributor, so a team of 40 costs more than a team of 8 on the same content model. Self-hosted Community editions do not charge per user, but paid self-hosted tiers may. Count editors by role, including reviewers and translators, and ask each vendor how its plans price admin users versus API or read-only users. Illustrative: a marketing team of 12 with 3 reviewers needs a different plan mix than a single-brand site with 2 editors.
Paid edition features required
Admin SSO, audit logs, review workflows and content history are often locked behind paid tiers, so the feature list drives the license line more than the seat count. In Strapi's self-hosted plans, SSO is an add-on at the Growth tier and is included in Enterprise, while audit logs and review workflows are Enterprise features. Write down which of these your governance requires before comparing totals, and confirm current tier contents with each vendor in writing.
Content model size and locales
The number of content types, components, relations and locales determines how much build and testing work is needed before launch and how much ongoing schema change follows. Large models with many locales increase modeling time, translation workflow setup and preview testing. Ask partners to estimate effort by content type and locale, and ask SaaS vendors whether document counts, locale counts or history retention change the plan you need.
Frontend build complexity
The CMS is only one part of the bill. The site or app that reads the API, handles preview, routing, search and caching is often the largest one-time build cost, and it is paid for separately from the CMS license. Choosing Next.js, a static generator or a native mobile client changes that effort. Ask for the frontend build to be scoped as its own line item, with preview and editor workflows included as deliverables.
Hosting and uptime targets
Managed CMS hosting is priced by project, API request, storage and bandwidth allowances, and some tiers attach an uptime SLA. Self-hosting moves that cost into cloud accounts, database operations, backups, monitoring and on-call coverage, which recur every month. Strapi Cloud's listed plans are 35 US dollars per month per project for Starter, 90 for Pro and 450 for Business, and only the Business tier carries a 99.9% uptime SLA. Compare the uptime you need against the plan that includes it.
Migration and major version changes
Moving content from an existing CMS, or upgrading a major version, is often the largest one-time cost in the first year. Strapi 4 reached end of life on April 30, 2026, so older projects face a v4 to v5 move that changes the API response format and replaces the Entity Service API with the Document Service API. Strapi's docs say to back up the database first because downgrading is not supported, so budget for backup, staging rehearsals and content remapping before any cutover.
What building in-house costs beyond the license
The license is the smallest line in a self-hosted headless CMS budget. Strapi Community Edition, Payload and the Directus core carry no license fee for the core product, so the real cost sits with the people who model content, build the frontend, run the hosting, patch the software, back up the database, upgrade the platform and train editors. Plan these as staffed roles with named owners. Content modeling is a one-time effort that grows with every new content type, locale and brand. Frontend work, hosting, security patching and backups recur for as long as the site runs.
Upgrades are the cost most teams underestimate. Strapi 5 minor releases have shipped roughly weekly (v5.56.0 on September 30, 2026 and v5.57.0 on October 7, 2026), so an upgrade calendar with test environments, regression checks on content APIs and a rollback plan is a recurring cost, not a one-off project. Strapi v4 reached end of life on April 30, 2026, so teams still on v4 also carry migration effort. Ask any partner to show how it will test each release before it reaches production.
Stack maintenance adds fixed obligations. Strapi 5 supports PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later and SQLite 3, and it does not support MongoDB or other NoSQL databases. It also runs only on Active or Maintenance LTS Node.js versions. Your team must track those Node.js lifecycles, keep the database within the supported range, and budget for the work of moving either one forward. Confirm the current support matrix with Strapi's installation requirements before you choose a database or hosting image.
How to build your own headless CMS cost estimate
This sequence turns a vague budget conversation into a dated, line-by-line estimate that compares in-house, partner and SaaS options over the same three years. Each step produces an input the next step needs, so the final totals can be checked against the same assumptions.
List content types and locales first
Start by inventorying every content type the site or app will need, such as articles, product pages, landing pages, navigation, banners and author profiles, along with the fields and relationships each one carries. Record which locales must be published and whether each one needs its own review path. Your product or content owner signs off on the list, and the output is a one-page model inventory with a locale count. Cost estimates are only as reliable as this list, because seats, storage, translation work and frontend templates all scale from it.
Pick the edition by required features
Map each requirement from the inventory to the platform edition that provides it. For example, check whether admin SSO, review workflows, audit logs, content history or releases are needed, and confirm which of these sit in the Community edition and which need a paid self-hosted plan. Strapi's self-hosted pricing page, Payload's licensing and Directus's license terms each differ, so record the edition and license for each candidate. The output is a feature-to-edition matrix that the security and legal reviewers have accepted.
Price hosting for each environment
List every environment you will run, typically development, staging, production and any preview or disaster recovery copy. For each one, estimate compute, managed PostgreSQL or equivalent, media storage, CDN and backups, and note who pays for each item: your cloud account, a hosting provider or a managed CMS cloud. Where a vendor publishes hosting tiers, such as Strapi Cloud's listed plans, record the monthly list price, its allowances and any uptime commitment, and state the date you pulled it. The output is a per-environment hosting table with monthly and annual subtotals.
Estimate frontend and integration scope
Scope the work outside the CMS itself: the frontend build that renders content, search, forms, the identity provider connection, analytics, CRM or commerce links, and any migration from an existing system. Ask the implementation partner for a written scope with named deliverables, and have your own team estimate the portions it will own. Output is a work breakdown with each item tagged as build, configure or integrate, plus the party responsible for it. Treat this as the largest source of variance, so keep it separate from platform licensing.
Add upgrades, support and security testing
Add the recurring work that keeps the platform current and defensible: version upgrades, dependency patching, backup and restore tests, monitoring, on-call coverage and periodic security testing of the API and admin panel. Pricing for these may come from your staff time, a support contract or a retainer, and each should be stated as a monthly or annual figure. Confirm the upgrade path for the major version you choose, since major version moves can require data migration. The output is a recurring cost schedule with the owner of each line.
Compare three-year totals across options
Build three columns with the same assumptions: in-house, partner-delivered self-hosted, and per-seat SaaS CMS. For the SaaS column, use the seat count and tier from the vendor's current pricing page and note that custom enterprise pricing requires a quote. Sum one-time costs, such as design, content modeling and migration, and recurring costs, such as hosting, licenses, seats and support, across three years. Vendor prices change, so confirm every figure on the current pricing page and date each one in the estimate. The finished comparison shows where the totals diverge and which assumptions drive the gap.
Questions buyers ask about headless CMS cost
Is the open-source headless CMS core really free to use?
Yes for the community code, but free to download is not the same as free to run. Strapi's Community Edition is MIT licensed outside its ee directories, Payload is MIT licensed, and Directus is under the Monospace Sustainable Core License, which permits internal use and professional services to deploy or host it for a licensee. The costs that remain are the hosting you pay your cloud or data center provider for, the database, media storage and backups, and the engineering time to model content, build the front end and operate upgrades. Paid self-hosted tiers such as Strapi's Growth and Enterprise plans add features like SSO and workflows, so confirm which features your requirements need before assuming the core covers them. Ask your license counsel to review the exact terms for your use case.
How much effort does a self-hosted headless CMS build take, and what does it need from us?
Effort is driven by the content model, not the software install. Expect work in four areas: modeling content types, relations and locales; configuring roles and editorial workflows; building the front end that reads the API; and setting up hosting, backups and monitoring. The client needs a named business owner who can sign off on the content model, editors who will test preview and publishing, an engineer who can run the database and deployment pipeline, and a security contact who can approve identity and network design. Ask any partner for a written breakdown of these phases and the client roles each one assumes, because the scope and timeline should follow from that list.
Can our team self-host the CMS without an implementation partner?
A capable internal team can install and run a headless CMS, but the harder work is the parts that fail in production: database and Node.js version alignment, upgrade paths between major versions, backups that restore, access control for editors and end users, and audit evidence. Strapi 5 documents specific supported databases and Node.js versions and does not support MongoDB, and its v4 to v5 migration requires a database backup first because downgrading is not supported. Assess your in-house skills against those tasks. A fixed-scope partner engagement can cover the parts your team does not run regularly, and a retainer can cover ongoing upgrades and support.
How long does a headless CMS launch take, and what makes it longer?
No general duration applies, because the timeline follows from the content model, the number of front ends, the migration load and the approval chain. Launches tend to run longer when content from a legacy system must be audited and remapped, when several locales or brands share one model, when SSO and review workflows need identity and legal sign-off, or when the front end is a new build. Ask for milestones tied to written deliverables and a list of client dependencies, and treat any single number without that breakdown as unverified.
When does SSO or audit logging force us onto a paid CMS tier?
Check the feature against the edition before you commit. In Strapi's self-hosted plans, SSO is an add-on for Growth and included in Enterprise, while audit logs and review workflows are Enterprise features. Strapi SSO covers administrator login to the admin panel only, and end-user login is handled separately by the Users and Permissions plugin. Payload includes built-in authentication for admin and customer users, and Directus provides role-based permissions for both humans and its MCP server. Ask each vendor in writing which edition includes SSO, audit trails, approval stages and retention, and whether those features cover your editors, your customers or both.
How does per-seat SaaS CMS pricing compare as the number of editors grows?
Per-seat SaaS cost rises in steps with each editor, so the comparison depends on editor count and the features each tier includes. As an example, Sanity's published Growth plan lists $15 per seat per month with up to 50 seats, and its Enterprise plan with SSO, longer history and audit trail is custom-priced. Self-hosted tiers are priced differently: Strapi's Growth plan is listed at $45 per month including 3 users plus $15 per extra user, and its Community Edition has unlimited users. Build a five-year model with your real editor count, hosting, backup, support and engineering costs on both sides, and include the cost of exiting either option.
What should we ask for in a headless CMS quote?
Ask for a written scope with the content model, number of front ends, locales, integrations, migration volume and environments listed. Request separate line items for the one-time build, data migration, hosting setup and the recurring hosting, support, upgrade and monitoring. Confirm which paid edition features are included, which license terms apply, which database and Node.js versions are supported, and how major upgrades are handled. Request the acceptance criteria and the client responsibilities. DeployOpen does not publish a price list, and a quote follows from a written scope.
When an implementation partner changes the total
A partner changes the total when it takes on work that otherwise falls to your own staff, and the clearest way to see that is to split the project into what the partner carries and what you keep. A typical DeployOpen engagement covers scoping, content modeling, the frontend build, hosting setup in your own cloud account or data center, hardening, documentation and handover. Your team keeps ownership of the content itself, the time its editors spend learning the tool and reviewing the output, and the business approvals that decide what goes live, including who signs off on brand, legal or regulated copy. Those last items do not move to a partner under any contract, so budget for them as internal cost from the start.
Ask for the scope in writing before any work starts. DeployOpen works on fixed-scope agreements, so the deliverables, the environments, the content types to be modeled, the number of frontends, the integrations and the handover materials should be listed in the statement of work. Ask the partner to state what is excluded, such as content migration from an existing system, translation, or custom editor plugins, because those exclusions are where unplanned cost usually appears. Confirm how changes to scope are priced and approved, and whether the Strapi, Payload or Directus edition you choose needs a paid license for the features in the plan, since that cost sits outside the partner's fee.
Once the platform is live, the cost that recurs is upgrades, security patches and monitoring. A retainer covers ongoing upgrades, support and continuous testing, and it is worth comparing against an internal on-call rota that your team would have to staff. Ask the partner how it tracks vendor release cycles, how it tests a minor release before applying it, and how a major version change would be scoped, because a major migration is a separate project. Also ask for the retainer's response targets in writing and check whether your own internal hours are still needed for approvals and content work, so the annual figure you compare against SaaS reflects the whole cost of ownership.
Which phases carry the most cost
The sequence below shows where effort concentrates in a self-hosted headless CMS project, from the first scoping conversation through run. Read it to see which costs happen once and which keep recurring after go-live.
Scope the content and the team
Discovery inventories the sites, apps and channels the CMS will feed, the content types on each, the editor roles, and the identity and hosting constraints. DeployOpen or your internal team documents the findings and the choice between Strapi, Payload or Directus, weighed against the license terms of each. The step closes when the client signs off a written scope that states which features need a paid edition, such as SSO or review workflows.
Model the content
Content modeling turns the inventory into collections or content types, fields, relationships, locales and draft states. Your content owners and front-end developers review the model against real pages and editor tasks, and changes are cheaper here than after the frontend is built. The output is an approved model with a sample dataset that the team can click through in the admin panel.
Build the backend and editor environment
Engineers install the chosen CMS in your cloud account or data center, connect it to a supported database such as PostgreSQL, configure roles, permissions, media storage and environments, and set up the paid edition features that were scoped. This is largely one-time work, although hosting, patching and database operations continue afterward. The step is done when editors can create, preview and publish test content in a staging environment.
Build the frontend and API integration
Frontend developers consume the CMS API from the sites or apps, implement preview, caching and build or revalidation triggers, and handle the locale and fallback logic defined during modeling. Frontend build is frequently the largest one-time line item because it is driven by design scope and the number of templates, so ask for it to be quoted separately. The output is a working staging front end that renders published content correctly.
Migrate existing content
If content already lives in a page-based CMS, a SaaS CMS or spreadsheets, the team maps fields, cleans duplicates, moves media and checks URLs and redirects. Migration effort rises with the volume of legacy content and the number of content formats, so it should be estimated from a sample extract rather than from the total count. The step closes with a reconciliation report that shows record counts and spot-checked pages match between source and target.
Test, secure and cut over
Testing covers content workflows, permissions, accessibility of the rendered front ends, performance under expected load, backup and restore, and security review of the API and admin panel. Cutover moves DNS, retires the old system or runs both in parallel for a defined period. The step is complete when test results are recorded, a restore has been proven and the go-live checklist is signed.
Run, patch and upgrade
After go-live, recurring costs include hosting, database and storage, security patching, version upgrades, monitoring, backups and editor support. Upgrades between major versions, such as the Strapi 4 to 5 path, carry their own one-time project cost and should be planned as a separate scope. Confirm in a written support plan who handles each recurring activity, the response expectations and what is covered by any retainer.
How DeployOpen scopes and delivers a fixed-scope headless CMS implementation
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a headless CMS cost decision, we start by writing down what is being compared, including the paid plans, hosting and build work each option would need, before any work begins.
How we scope
- Written scope listing the CMS product, edition, hosting model and the number of editors and content types in use
- Cost comparison covering self-hosted community features, any paid self-hosted plan add-ons, and per-seat SaaS quotes side by side
- Written list of which paid features your requirements need, such as admin SSO, audit logs or review workflows, confirmed with the vendor
How we build
- Content model design and frontend build sized to the scope agreed in writing, with the build effort itemized
- Deployment into your infrastructure with database, media storage and backup configuration documented as part of delivery
- Testing of content models, editor roles, preview and API responses against the requirements in the written scope
How we hand over
- Documentation of the hosting setup, licensing position, upgrade path and the paid plan features that were deployed
- Handover of the content model, admin roles and integration points to your team, with a record of what was configured
- Clear list of recurring costs you carry after handover, including hosting, licenses, seats and your internal ownership
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build
- Upgrade planning for future major versions, with the migration steps and rollback considerations written down before work starts
- Confirm with us during scoping which support level and response expectations apply, so they appear in the written agreement
