Blog
Hosted headless CMS vs self-hosted
Search for a headless CMS and you hit the same fork early: pay a vendor to run it, or run it yourself. Hosted SaaS (Sanity, Contentful, Storyblok, NomaCMS) vs self-hosted installs (Strapi, Payload, Directus, ElmapiCMS) is not a feature checklist. It is an ops and ownership decision.
This post is a general comparison. It covers what each model actually costs you, when self-hosting wins, when hosted wins, and how end-user auth (signup and login for your customers, not CMS editors) changes the total stack. Use it to shortlist, then run a week-long proof of concept.
Disclosure: We build NomaCMS (hosted) and ElmapiCMS (self-hosted). We name both as concrete examples of each model. Competitor examples below are the same shortlist teams usually compare. Neither product wins every use case.
What “hosted” and “self-hosted” mean
| Hosted (SaaS) | Self-hosted | |
|---|---|---|
| Who runs the CMS | The vendor | You (or your client’s infra) |
| Where data lives | Vendor cloud | Your VPS, cluster, or private cloud |
| How you pay | Subscription (often seats + usage) | License and/or server bill + your time |
| Typical examples | Sanity, Contentful, Storyblok, NomaCMS | Strapi, Payload, Directus, ElmapiCMS |
Some products offer both (Strapi Cloud, Directus Cloud, Payload Cloud). Treat those as hosted for the ops row and self-hosted when you install the open-source core yourself.
“Headless” is orthogonal. Both models expose content over an API. The fork is who owns uptime, upgrades, backups, and security patches.
Decision questions (answer these first)
- Who edits content? Developers only, or marketers and clients too?
- Who gets paged at 2am? You, a DevOps hire, or nobody on your team (the vendor runs the CMS)?
- Must data stay on your infra? Compliance, client contracts, or preference?
- How many sites? One product, or an agency with many similar builds?
- Do you need end-user login? Members, customers, or app users, separate from CMS seats?
Your answers matter more than GitHub stars.
Side-by-side: what actually differs
| Dimension | Hosted | Self-hosted |
|---|---|---|
| Time to first publish | Usually hours: sign up, model, fetch | Days if you count install, DB, TLS, backups, staging |
| Ongoing ops | Vendor handles OS, DB, scaling | You own updates, migrations, monitoring, restores |
| Cost shape | Predictable monthly fee; can climb with seats/API | Server + license + your hours; can stay flat at scale |
| Data ownership | Vendor controls the store; export matters | Full control of DB and files |
| Editor UX | Polished dashboards by default | Varies: some excellent, some developer-first |
| Customization depth | Bounded by the product | You can patch, plugin, or fork (with maintenance cost) |
| Multi-project / agency | Often one cloud project per client | One install can serve many projects (product-dependent) |
| End-user auth | Usually a second vendor, unless the CMS includes it | Often plugins or custom code, unless the CMS includes it |
Pricing changes often. Treat any dollar figures as directional and check vendors before you buy.
When self-hosted wins
Self-hosting is the better default when:
- You already run infra and adding one more app is cheap compared with SaaS seats across many sites
- Contracts require data residency or “CMS on our servers”
- You want the schema in Git next to the app (Payload-style TypeScript CMS-in-repo)
- Agency economics favor one install, many client projects, and a one-time license instead of N SaaS bills
- Idle cost matters and your stack is light (for example Laravel-friendly hosting vs heavy Node CMS processes)
Concrete example on our side: ElmapiCMS is a self-hosted Laravel headless CMS with multi-project from one install and a $70 one-time license. You own the box. You also own backups and upgrades.
Trade-off: every “free” open-source install still costs someone’s night when Postgres fills the disk or a plugin breaks after an upgrade.
When hosted wins
Hosted is the better default when:
- You want zero CMS servers (solo founders, small product teams, freelancers who refuse pager duty)
- Editors need a reliable dashboard without you babysitting Node or PHP processes
- Time to ship beats perfect infra control for the first product version
- You prefer one subscription bill over DIY monitoring and patch nights
- Compliance is “good enough” with a reputable SaaS DPA, not “must be on our VPS”
Concrete example on our side: NomaCMS is a hosted headless CMS. Collections and fields in the dashboard, REST API and @nomacms/js-sdk, webhooks, locales, MCP for AI editors. Basic from $15/mo with a 7-day free trial. Core capabilities (API, SDK, MCP, project auth, webhooks, locales) are on every plan; tiers mainly raise projects, seats, API volume, and storage.
Trade-off: you depend on a vendor for uptime and roadmap. Export and API design matter if you might leave later.
The auth line item most comparisons skip
CMS comparisons often count editor seats. Product apps also need end-user auth: signup, login, refresh, logout, sessions for customers or members.
That is a different credential from “who can open the CMS dashboard.”
| CMS editor access | End-user (project) auth | |
|---|---|---|
| Who | You, your team, client editors | People using your site or app |
| Typical approach | Built into every CMS | Often Clerk, Auth0, Supabase Auth, Firebase, or custom JWTs |
| Ops | One product | Second product, second docs, second bill |
Self-hosted stacks often bolt on plugins (for example Strapi Users & Permissions) or custom JWT middleware. That can work. You still own security patches, password reset flows, and session storage.
Hosted stacks often assume you add a separate auth vendor. That also works. It means two dashboards and glue code every time tokens expire.
Some hosted products include project auth next to content. NomaCMS does: signup, login, sessions, profile, email verification, and user-owned API keys per project, so many Next.js / Nuxt / Astro apps skip a second auth vendor. That is a positioning choice, not a law of nature. If you only need a marketing site with no members, ignore this row.
When you compare TCO, add:
- CMS subscription or servers
- Auth vendor (if separate)
- Hours spent explaining both stacks to teammates and AI coding agents
Agency and multi-site pattern
Agencies feel the fork hardest.
| Pattern | Typical choice | Why |
|---|---|---|
| Many similar client sites, you already run VPS | Self-hosted multi-project | One install, shared ops, predictable license |
| Clients hate “another server,” you hate on-call | Hosted, one cloud project per client | Isolation without N CMS boxes |
| Client must own the data on their cloud | Self-hosted on their account | Contract wins |
| Product app with member login + marketing content | Hosted with auth in the same platform, or CMS + Clerk | Fewer moving parts for a small team |
Neither pattern is morally superior. Match the pattern to who pays for ops.
A simple decision tree
Must data live on your (or the client’s) servers?
yes → Self-hosted (or private cloud install)
no → Continue
Do you want zero CMS ops and a managed dashboard?
yes → Hosted SaaS
no → Self-hosted (you accept updates and backups)
Is the product more than a brochure site (members, accounts)?
yes → Factor end-user auth into the same shortlist
no → Compare editor UX, API, and price onlyHow to run a fair one-week POC
- Model the same three collections in a hosted trial and a self-hosted install (or two hosted products if infra is already off the table).
- Fetch published content from a real Next.js, Nuxt, or Astro page.
- Time first publish to live page, not only schema creation.
- If you need members, implement one login path and count vendors touched.
- Write down who would own backups and upgrades in production. If the answer is “nobody,” pick hosted.
Where to go next
If you want hosted content plus project auth without a second auth bill, start with NomaCMS (7-day free trial, Basic from $15/mo). If you want self-hosted multi-project on your own servers, look at ElmapiCMS. For a wider 2026 shortlist (Sanity, Contentful, Strapi, Payload, and more), see Best headless CMS in 2026.