Strapi's paywall isn't drawn at traffic — it's drawn at your org chart. SSO, audit logs, and per-locale permissions are all Enterprise. Here's the real bill for Community self-hosted, Strapi Cloud seats, and the v5 upgrade nobody budgets for.
The free tier usually ends as a spreadsheet attachment. Ours arrived in week nine of a build: forty-one security-review questions from the client's insurer, three of which were "can editors be restricted to a subset of content," "is there a tamper-evident log of publish and unpublish events," and "do you support SAML." Strapi Community answers no, no, and no. We had thirty-eight content types modelled, a Next.js frontend already consuming the REST API, and two weeks to launch.
Strapi is genuinely MIT-licensed and genuinely free to self-host — we run it in production and would pick it again tomorrow. But its pricing is a feature cliff, not a usage curve. Community is complete for building and empty for governing. Every unbudgeted Strapi bill we have watched land traces back to the same move: pricing the build, then not pricing the second year of running it with more than three people in the admin panel.
Community gives you the content-type builder, REST and GraphQL, draft and publish, i18n, API tokens, the media library, and exactly three admin roles: Super Admin, Editor, Author. That ships a marketing site, a docs portal, or an app backend with a small editorial team. On the paid side sits everything an organisation asks for once the CMS matters: custom roles with field-level permissions, SSO/SAML, audit logs, review workflows, content history, and release scheduling.
Read that list again, because it describes the shape of the trap. Not one of those is a scaling feature. You don't hit them at traffic, you hit them at headcount and at process. A twelve-person team with a legal approval step needs review workflows on day one and does not care that the API serves 500 requests a second behind a CDN. A single-editor site doing four million pageviews a month can stay on Community indefinitely. The paywall runs across your org chart, so estimate cost from who will hold an admin login in eighteen months.
Permissions are the item discovered latest and hurt most. Community's three roles apply globally — they scope by content type, never by row, never by locale. So the day a client says "the German team edits German entries and nothing else," you are buying a licence, writing a plugin against the admin RBAC layer, or running one Strapi instance per region with a shared media bucket. We took the plugin route once: about 600 lines hooking the permission engine and the entity-level policies. It worked, it broke on two minor upgrades, and it had to be rewritten wholesale for v5. That maintenance cost more than the licence it avoided.
Cloud runs it for you: managed Postgres, assets on a CDN, git-push deploys, and the governance features bundled into the upper tiers. Published prices move, so check them the week you decide, but the shape has been stable for two years — an entry tier around $29 per project per month, a middle tier near $99, a scale tier in the mid-hundreds, and quoted enterprise above that. Every tier caps seats, API calls, bandwidth, and asset storage, and bills overage past the cap.
The line that surprises finance is seats. Cloud counts admin users, and content headcount grows in a way engineering headcount doesn't: a freelancer for one campaign, a regional editor, an agency reviewer who logs in twice a quarter and still costs a seat. Model per project as well. Three brands almost always means three projects, because Strapi has no tenant isolation — one database, one admin panel, one role set — and separating brands means the same permission plugin you were trying to avoid. That's three $99 lines, not one.
Cloud is still right for plenty of clients. If your team is four engineers and none of them wants to own a Postgres major-version window at 2am, a few hundred a month to never think about it is cheap. The mistake is comparing Cloud's monthly price to self-hosting's monthly price, which is not the comparison.
Infrastructure is the easy half. A 2GB container for the app, managed Postgres, S3 or R2 with the upload provider actually configured, and a CDN in front. That runs $50 to $150 a month for a typical B2B site, and it barely moves with traffic, because a static or ISR frontend should be reading from a build and a webhook, not proxying every request through the CMS.
The cost is engineering time, and it lands in predictable places. Strapi compiles its admin panel at build time, so every plugin or config change needs a build step — and that build wants more than 1GB of heap, which is why the most common first-deploy failure is an OOM kill during `strapi build` rather than anything to do with the app. A close second: leaving uploads on the local filesystem, so every redeploy of an ephemeral container silently drops the media library. Minor upgrades are routine. The v4-to-v5 jump was not: the Document Service replaced the Entity Service, entries became addressable by `documentId` instead of a numeric id, and drafts became separate documents, so every custom controller, populate call, and frontend query holding an id had to be rewritten. Budget a day a quarter for upkeep and a full week for a major version — roughly $6k to $12k a year at agency rates. That is the number to hold against Cloud, not the $60.
Self-hosted Enterprise is a separate purchase, licensed per project and quoted annually; plan on five figures for SSO and audit logs on your own hardware. If those two features are the only reason you're considering it, price the Cloud tier that bundles them first. It is usually less.
Fewer than five admin logins and no compliance requirement: Community, self-hosted, and put the saved budget into the frontend. A content team with an approval chain, or a security review that says SSO: buy the Cloud tier that already includes it and stop rebuilding governance yourself — permissions code is the worst code to own, because it fails silently and only in production. Features required on your own infrastructure for data residency: get the Enterprise quote in week one, because it frequently changes which CMS you choose.
Decide before you model content. The expensive Strapi migrations we get called into are never about hosting. They're teams who built forty content types on Community, found the governance gap in month six, and then had to move a live editorial workflow — which means re-keying relations, rebuilding the redirect map, and retraining editors mid-quarter. Pick the edition against your second year, then build.
A software studio that ships and maintains its own products — KeepChats, Gwora and Cairn — and builds the same way for clients. Founded and led by codewithumar.
Talk to the studio →Send the problem. You get one fixed number and a plan back within a business day.
We build software worth keeping — for clients, and for ourselves.
Founded & led by codewithumar