When is the free Strapi Community Edition enough?
Strapi Community covers the core of a headless CMS: content modeling, the REST and GraphQL APIs, and unlimited entries and API calls under the MIT Expat license. If your team needs a self-hosted backend that editors can populate and front ends can read now, and nobody has yet asked for admin login through your corporate identity provider, an audit trail of who changed what, or an approval step before publishing, the free edition may be the right choice. Community also includes no content history and no releases, so plan any rollback process around your own database backups from the start.
The paid tiers become relevant when those operating requirements turn into compliance obligations. SSO for the admin panel is a Growth add-on and is included in Enterprise, and it covers only administrator login, not end-user authentication, which stays with the Users and Permissions plugin. Audit logs and review workflows are Enterprise only. Content history and releases start at Growth, with 14 days of content history retention on Growth and custom retention on Enterprise. Ask Strapi to confirm the current retention terms in writing, and check whether your auditors expect logs or history for longer than the plan provides.
Choose Growth when you need SSO and content history but not audit logs or review workflows, and when a small, fixed number of users fits the seat model. Choose Enterprise when audit logs, approval workflows or offline licensing are required, or when you need custom support levels. Before committing, map each control your auditors or internal policies require to a specific feature on the Strapi self-hosted pricing page, then confirm the edition in writing with Strapi. If a requirement cannot be met by Community, and you cannot meet it through your own logging or process, the paid tier is no longer optional.
Which Strapi features need Growth or Enterprise?
This table maps each feature named in Strapi's self-hosted plan documentation to the edition that includes it, so you can see which controls require a paid license before you commit. Read each row against your own requirements: if you need SSO, audit logs or review workflows, the row tells you which plan to price. Confirm current plan contents with Strapi before you sign, because the split is set by the vendor.
| Feature | Community (MIT, free) | Growth and Enterprise |
|---|---|---|
| REST and GraphQL APIs | Included | Included in Growth and Enterprise |
| Unlimited entries and API calls | Included | Included in Growth and Enterprise |
| SSO for admin panel login | Not included | Growth add-on at 150 US dollars per month plus 50 dollars per user per month; included in Enterprise (Strapi self-hosted pricing page) |
| Content history | Not included | Growth includes 14 days of retention; Enterprise lists custom retention |
| Releases | Not included | Unlimited releases from Growth; confirm limits with Strapi |
| Audit logs | Not included | Enterprise only |
| Review workflows | Not included | Enterprise only |
| Offline licensing | Not included | Enterprise add-on |
| Support level | Community support | Growth: basic support; Enterprise: custom support with Standard and Premium add-ons |
How licensing and support differ by edition
Strapi's three self-hosted tiers differ in two ways: the license that covers the code you run, and the support you can expect when something breaks. Read the license split first, then match each support tier to how much vendor help your team needs.
MIT Expat license for core code
Code outside the ee directories of the strapi/strapi repository is licensed under the MIT Expat license when you have no Strapi Cloud account. Community Edition runs entirely on this code, so you can self-host it, modify it and redistribute it under MIT terms. Check with your legal team whether your use case involves a Strapi Cloud account, because the license text ties the open license to that condition.
Proprietary license for ee directories
Code in ee directories carries a separate proprietary Enterprise license, not MIT. Features such as audit logs and review workflows live in that code, so using them means accepting Strapi's Enterprise terms. Ask Strapi which features ship in ee directories and which terms apply to your deployment before you build a workflow that depends on them.
Community support expectations
Community Edition gets community support, which means help from the public forums and community channels rather than a contracted response. A small team running a single internal site can accept that model. Teams with an uptime obligation or a regulator's expectation for a named escalation path should not treat community support as a substitute for a contract.
Basic, custom and offline licensing
Growth includes basic support, while Enterprise provides custom support with Standard and Premium add-ons. Offline licensing is an Enterprise add-on, which matters if your Strapi instance runs in an air-gapped or restricted network that cannot reach licensing servers. Ask for the exact response times, escalation path and update terms in writing before you sign, because these are contract items rather than product features.
Confirm update terms in writing
Support tiers and upgrade rights are separate questions. Ask Strapi whether your tier includes patch releases, minor releases and access to the migration guidance for the current major version, and whether those terms change if you run Strapi with custom ee code. Get the answers in the order form or the contract so your upgrade plan rests on documented terms.
How seat-based pricing changes the Growth bill
The number of people who sign in to the Strapi admin panel is the variable that moves a Growth bill. The Community Edition is free with unlimited users, so seat count only matters once you choose a paid self-hosted plan. Growth is listed at 45 US dollars per month, which includes 3 users, and each additional user adds 15 US dollars per month. Enterprise is custom priced and requires a direct quote. Before you model the cost, list every admin-panel account by role: content editors, administrators and anyone who reviews entries. Each one is a seat to count. Review workflows are an Enterprise feature, so a reviewer account on Growth does not give you an approval gate, and that gap should be settled before you buy seats.
SSO is where the bill changes shape. On Growth, SSO is an add-on at 150 US dollars per month plus 50 US dollars per user per month, on top of the base fee. As an illustrative example, a team of 6 admin-panel users on Growth would pay 90 US dollars for the base plan (45 dollars plus 45 dollars for three extra users). If the SSO fee applied to all six seats, SSO would add 450 US dollars, for a total of 540 US dollars per month. Confirm with Strapi whether the per-user SSO fee applies to every seat or only to accounts that sign in through the identity provider, because that answer changes the total. Also remember that SSO covers administrator login only, so end-user authentication is handled by the Users and Permissions plugin and your website visitors are not admin seats.
These figures are Strapi's published list prices on its self-hosted pricing page, and they can change. Treat them as a starting point, not a quote. Ask Strapi for a written quote that states the seat count, the SSO add-on, taxes, the billing period and whether support tiers are included. Also ask how a deactivated user is counted in the middle of a billing cycle, and whether you can move from Growth to Enterprise without rebuilding your admin setup. Get these answers in writing before you commit an annual budget, and recount your seats after each hiring or contractor change.
What each Strapi edition costs to run
This table breaks the running cost of Strapi Community, Growth and Enterprise into its components, showing who is paid, whether each item is one-time or recurring, and what moves it up or down. Use it to build a like-for-like quote request, since only some components have published list prices.
| Cost component | Community | Growth and Enterprise |
|---|---|---|
| License fee | Free under the MIT Expat license for the Community Edition code (Strapi LICENSE file) | Growth is listed at 45 US dollars per month including 3 users (Strapi self-hosted pricing page). Enterprise is custom pricing, so request a written quote. |
| Seat and SSO add-ons | Unlimited users, no SSO or audit logs included | Growth adds 15 dollars per month per extra user. SSO is a Growth add-on at 150 US dollars per month plus 50 dollars per user per month, and is included in Enterprise (Strapi self-hosted pricing page). |
| Hosting and database | You pay your own cloud or data center costs, plus a supported database such as PostgreSQL, MySQL, MariaDB or SQLite. Confirm the database tier with your team | Same infrastructure model as Community. Growth and Enterprise do not replace your hosting bill, so size the environment, backups and any staging copies yourself |
| Support contract | Community support only, from the community | Growth gets basic support. Enterprise gets custom support, with Standard and Premium add-ons. Ask which response windows are in writing before you sign |
| Internal administration | Recurring staff time for Node.js runtime updates, plugin review, user administration and backups | Recurring staff time as in Community, plus managing SSO configuration, audit log review and review workflow ownership |
| Upgrade effort | One-time per major version, plus recurring minor updates. Strapi v4 reached end of life on April 30, 2026, so v4 estates carry a one-time migration cost (Strapi v4 to v5 migration docs) | Same one-time migration pattern. Migration is not free of effort: plan for codemod review, data migration checks and a database backup, since downgrading is not supported |
| What drives cost up or down | Number of environments, database operations, and how much custom code your team maintains | Seat count, number of SSO users, retention needs for content history, and the scope of the Enterprise quote, including offline licensing if you need it |
How to move from Community to a paid tier
This sequence takes a team from the free MIT-licensed Community Edition to a Growth or Enterprise plan with a clear list of which features are needed, which plan or add-on covers them, and how permissions were checked before production. The result is a documented upgrade that the team can explain to finance, security and the Strapi account contact.
List the paid features you actually need
Start by writing down each capability the team cannot work without, such as SSO for admin login, audit logs, review workflows, content history or releases. Check each item against Strapi's self-hosted pricing page, because SSO sits in the Growth add-on and in Enterprise, audit logs and review workflows are Enterprise only, and content history and releases begin at Growth. The step is done when every requirement is mapped to a plan or add-on, with an owner for the list.
Confirm the plan and seat count
Work out the number of administrator seats you need, since Growth is listed with 3 users included and an extra charge per additional user, while Enterprise is quoted custom. Ask Strapi sales to confirm current seat pricing, the SSO add-on terms, and whether offline licensing is needed, because that is an Enterprise add-on. Your finance lead should receive a written quote that shows recurring charges separately from any one-time items. The step is done when the quote matches the feature map from the previous step.
Verify license terms and scope before purchase
Confirm with your legal or procurement team that the code you run stays under the MIT Expat license outside the ee directories, and that any paid code under ee directories falls under Strapi's separate Enterprise license. Ask Strapi to state in writing how the paid features are enabled on your existing project and what applies to the code already in production. The step is done when procurement has the license terms on file and the team knows which parts of the codebase carry the Enterprise license.
Stage the upgrade on a copy of the project
Enable the purchased features on a staging copy of the Community project, which uses the same database engine and Node.js version as production. Paid features are licensed capabilities layered on the same project, so the code, content types and data do not need to be rebuilt. Record the Strapi version and the license state in the change ticket. The step is done when staging runs with the paid features on and the content model matches production.
Configure SSO for administrator login
Connect the identity provider, such as Microsoft Azure Active Directory, for administrator login to the admin panel. Set auto-registration, the default role and whether local login is locked out, and test with a set of named accounts. Remember that SSO covers only admin panel login, while end-user authentication stays with the Users and Permissions plugin. The step is done when test administrators sign in through the identity provider and the fallback login behaves as the security team intended.
Enable review workflows, audit logs and content history
Turn on review workflows, audit logs and content history or releases, based on the feature map. Run a sample content item through a full review cycle, then publish a release and check that the audit trail records who changed what. For Growth, confirm the 14-day content history retention is acceptable, and for Enterprise, confirm the custom retention with Strapi. The step is done when the audit trail and review history are complete on staging and the retention terms are written down.
Test permissions and roles on staging
Build a test matrix of editor, author, reviewer and administrator accounts, and check each role against the content types, review steps and release actions it should and should not reach. Include SSO accounts with the default role and any accounts that were previously assigned roles manually. Log the results and fix any gaps before the change window. The step is done when every role has a signed-off test result and no unexpected access remains.
Confirm downgrade implications with Strapi
Before the production change, ask Strapi in writing what happens to SSO, audit logs, review workflows, content history and releases if you later move back to Community or drop an add-on. Ask how retained audit and history data is handled and whether any configuration is removed. Record the answers in the runbook and share them with the security owner. The step is done when the answers are on file and the rollback plan reflects them.
Why SSO covers admins only, not end users
Strapi SSO governs administrator login to the Strapi admin panel and nothing else. On the self-hosted plans, SSO is a Growth add-on or part of Enterprise, and it connects the admin panel to an identity provider such as Microsoft Azure Active Directory. When it is configured, the settings control auto-registration of new administrators, the default role they receive, and an optional lock-out that disables local admin login. Those are decisions for the team that operates Strapi, so they should be made with the identity team before the add-on is purchased, not after.
End-user authentication is a separate concern. Strapi documents that customer and member logins are handled by the Users and Permissions plugin, which is available in every edition, including Community. An SSO license for administrators does not give your website or application visitors single sign-on, and it does not replace the Users and Permissions setup. If your product has customer accounts, plan that authentication design on its own track, including how sessions, password policies and any external identity federation will work with your front end.
Before you buy, confirm the integration in your own environment. Ask Strapi which identity providers and protocols your setup needs, test the admin login flow end to end in a staging instance, and verify the default role and lock-out behavior against your access policy. The Strapi SSO documentation is the starting point, but the result should be checked against your tenant configuration, not assumed from the feature list.
Questions buyers ask before upgrading Strapi
Is Strapi Community edition production-ready for a regulated business?
Community can run production workloads under the MIT Expat license at no license fee, but it includes neither SSO, audit logs, review workflows nor content history, and its support is community support only. Whether that is acceptable depends on your controls, so the answer is set by your requirements rather than by the software alone. Before you commit, confirm which identity, audit and recovery requirements need a licensed feature, and name the person who will track Strapi's frequent releases. Strapi 5 minor releases have shipped roughly weekly, so a patching routine matters as much as the tier. Confirm in writing what response expectations Strapi offers Community users, and check that your Node.js and database versions are on the supported list before go-live.
What drives the Growth and Enterprise bill for a self-hosted Strapi?
Seat count drives most of the Growth price, and Enterprise is quoted individually. Growth lists at 45 US dollars per month including 3 users, plus 15 dollars per extra user, according to the Strapi self-hosted pricing page. Add-ons change the total: SSO on Growth is 150 US dollars per month plus 50 dollars per user per month, while SSO is included in Enterprise. Offline licensing and the Standard and Premium support add-ons also alter an Enterprise quote. Recurring costs are the subscription and per-user charges. One-time costs include your own migration and configuration work, which the vendor price does not cover. Ask for a written quote that lists seats by role, each add-on, the support tier and the billing terms, so you can compare it with the cost of running the same features yourselves.
How long does moving to a paid tier take, and what does it need from the team?
No duration for a tier change is supplied for this page, so confirm timing with Strapi and in your written scope before you set a date. The effort depends on which features you need. Someone must assign seats, decide who holds administrator roles, and set content history and release practices. If you add SSO, an identity administrator must register the application and map identity provider groups to Strapi roles. Engineers should confirm whether any configuration change or redeploy is needed after the plan change, and test the admin login path in a non-production instance first. DeployOpen plans and implements these changes under a fixed scope agreed in writing, so the scope document should name the owner on your side for each step.
Can our team configure SSO for Strapi admin login without outside help?
Often yes, if your team already administers an identity provider and has Strapi admin access, but confirm the steps in your own environment first. Strapi SSO covers administrator login to the admin panel only, through an identity provider such as Microsoft Azure Active Directory. Configuration includes auto-registration, a default role for new administrators and an optional lock-out of local login. End-user authentication is handled separately by the Users and Permissions plugin, so SSO does not replace it for your application users. On the self-hosted plans, SSO is a Growth add-on or is included in Enterprise. Your team needs application registration rights in the identity provider, a role mapping plan and a rollback path if login breaks. If internal skills are thin, DeployOpen can scope and implement the integration in writing.
What does content history retention mean on Growth compared with Enterprise?
Retention is how far back Strapi keeps content history you can review and restore, so it sets a limit you must plan around. Growth includes content history with 14 days of retention and unlimited releases. Enterprise lists custom content history retention, so the length is set in the Enterprise quote. Community includes neither feature. A 14-day window may suit short editorial recovery, but it may not match an internal policy that requires longer record keeping. Compare the window with your change and recovery requirements. Ask Strapi what happens to history older than the window, how restores are performed, and which data the history covers. Content history is not a replacement for database backups, which you still need to run and test.
What does the Strapi v4 to v5 upgrade change for licensing and effort?
The upgrade does not change which license applies to which code: MIT Expat covers code outside ee directories, and the proprietary Enterprise license covers ee code. Effort is the larger factor. Strapi v4 reached end of life on April 30, 2026, and its final release, 4.26.2 of June 9, 2026, receives no further updates. Strapi provides a codemod-based upgrade tool, data migration scripts that run on the first start of Strapi 5, and a breaking changes list. The Document Service API replaces the Entity Service API and the response format changes, with a Strapi-Response-Format: v4 header available during migration. Strapi 5 also drops MongoDB. Back up the database first, because downgrading is not supported. Read the migration introduction and FAQ before estimating your team's work.
Which Strapi features require the Enterprise plan specifically?
Audit logs, review workflows and enterprise plugins require the Enterprise plan, according to Strapi's documentation. Growth covers content history and releases, and SSO is a Growth add-on that is included in Enterprise. If your governance needs center on audit trails or editorial approval, Growth will not meet them, and the decision moves to an Enterprise quote. Confirm with Strapi which events the audit log records, how long entries are kept and where they are stored, because those details determine whether the log meets your monitoring needs. Also confirm which plugins Strapi classes as enterprise plugins. Get these answers in writing before you compare totals, since an Enterprise quote with custom terms cannot be read directly against a Growth list price.
How Strapi version upgrades affect edition planning
The upgrade work that matters most for this decision is the same whichever edition you run. Strapi 5.58.0 was released on October 14, 2026, and Strapi 5 minor releases have shipped roughly weekly, with v5.56.0 on September 30 and v5.57.0 on October 7, 2026. Strapi v4 reached end of life on April 30, 2026, and its final release, 4.26.2 of June 9, 2026, will receive no further updates. If your team is still on v4, the move to v5 is a platform upgrade that Community, Growth and Enterprise users all have to make, so it should not be counted as a reason to buy a higher tier. Confirm your current version and your plan for the v4 to v5 move before you compare license costs.
Strapi provides an upgrade tool with codemods for the v4 to v5 move, data migration scripts that run on first start of Strapi 5, and a breaking changes list. Plan for the largest code change in the Document Service API, which replaces the Entity Service API, and for the changed API response format. The Strapi-Response-Format: v4 header is available for backward compatibility during migration, so ask your team how long custom front ends and integrations will need it. Also check that the target Node.js version is on Active or Maintenance LTS and that your database is PostgreSQL, MySQL, MariaDB or SQLite, since Strapi 5 does not support MongoDB.
Treat the database backup as a hard gate. The migration documentation advises backing up the database first because downgrading is not supported, so a failed upgrade is recovered from a backup, not by rolling back the code. Build that into the change plan: a tested restore, a named owner for the cutover, and a window for re-testing roles, permissions and any SSO configuration on the admin panel. Those checks apply to Enterprise SSO and to Community login alike. Ask whether a version upgrade on your edition needs a vendor-assisted review, and confirm with Strapi how much of the work they support.
How DeployOpen scopes a Strapi edition decision
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so the edition choice is treated as an input to the written scope rather than a purchase made before scoping starts. We work through which admin, audit, review and content features your team actually needs and what that means for your environment.
How we scope
- Written scope lists which Strapi edition features your team needs, such as admin SSO, audit logs, review workflows or content history.
- The scope records your hosting footprint, Node.js and database choices, and the number of administrator seats you expect to license.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work begins.
How we build
- We install Strapi in your cloud account, data center or air-gapped network and confirm the Node.js and database versions it supports.
- We configure admin SSO only where a licensed plan includes it, and we test local login lock-out and default role assignment.
- We test content history, releases and permissions against the plan limits you have chosen, and record any gaps for your decision.
How we hand over
- Handover documentation covers the edition in use, the license terms that apply, and the seat count the configuration assumes.
- We document backup steps, including a database backup before any version change, and the upgrade path for your chosen edition.
- We walk your team through admin roles and license-dependent features so they know which settings depend on a paid plan.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the initial handover is complete.
- If you move from Community to Growth or Enterprise later, we can scope that change as a separate written engagement.
- Ask for a quote built from the written scope, and confirm current plan prices and features directly with Strapi before signing.
