Strapi is a self-hosted headless CMS: editors manage content in its admin, and it serves that content as an API to whatever consumes it. It earns its place when a website, a mobile app and possibly a partner all need the same content.
What is Strapi?
Headless means the CMS has no front end of its own. It stores content and exposes it over an API; how it is displayed is entirely someone else's decision. Strapi is the self-hosted option in that category — you define content types in its interface, and it generates the API and the editing screens.
Being self-hosted matters for data residency, which is a real constraint for some clients here, and it means no per-record pricing as the content grows.
In practice a Strapi project is two deployments rather than one: the CMS and whatever renders the content. That is the cost. The benefit is that adding a third consumer later — a mobile app, a partner feed, a second regional site — is a new client of an existing API rather than a new content system.
When we choose Strapi
When more than one thing consumes the content — a website and a mobile app, or several regional sites sharing a catalogue. One editing interface feeding all of them beats maintaining the same content twice.
When data must stay on infrastructure the client controls, which rules out the hosted alternatives.
When we do not use Strapi
For a single website. A headless CMS adds a second system to deploy, secure and update in exchange for flexibility a one-front-end site never uses. A custom CMS inside the application is simpler and gives editors a better-fitting interface.
And when the client wants to see the page while editing it. Headless means previewing is something we build, and it is never quite as immediate as editing in place.
What we build with Strapi
One content source, several destinations
A website, a mobile app and a partner feed all reading the same records. Content is entered once, in both languages, and every destination stays in step by construction.
Product catalogues shared across regions
One catalogue, several country sites, each overriding pricing and availability locally while inheriting descriptions and imagery. Editors maintain the shared content once.
Content for a website and a mobile app
The same articles, offers and notices reaching both, so a change published once appears everywhere. The alternative is two content systems that drift apart within a month.
Editorial workflow with roles
Draft, review and publish states with permissions that match how the team actually works, plus preview so an editor sees the page before anyone else does.
Migrations off a legacy CMS
Moving years of content out of a system nobody wants to maintain, with the structure improved on the way rather than copied across unchanged. Old URLs are redirected so the search ranking that content earned survives the move.
How we ship Strapi projects
With preview built for the editors, because a headless CMS without preview is a downgrade from what they had before and they will say so.
Self-hosted alongside the rest of the stack, backed up with the database, and with roles configured so an editor cannot change content types by accident.
With the content model agreed before any of it is built. Changing a content type after editors have entered a thousand records is a migration rather than an edit, and the hour spent on the model at the start is the cheapest hour in the project.
What Strapi costs you
It is another service to run, patch and back up, and major version upgrades have historically required migration work.
Preview and draft workflows need building rather than arriving free, which is the most common complaint editors have when moving to headless.
Upgrades between major versions have historically needed real migration work rather than a package update, so a Strapi project carries a maintenance commitment that a CMS inside your application does not.
Strapi questions we get asked
Only if more than one thing consumes the content. For a single website it adds a system to maintain in exchange for flexibility you will not use — a custom CMS inside the site is simpler and usually nicer to edit.
In a database you host — usually PostgreSQL — on infrastructure you control. That is the main reason to pick it over a hosted headless CMS, and for clients with data residency obligations in the GCC it is often the deciding factor.
Only if nobody builds it. Preview is real work rather than something that arrives free, and it is the most common complaint from teams moving to headless. We build it into the scope rather than treating it as an extra.
The core is open source and free to run. Some features — advanced roles, audit logs — sit behind a paid tier, and you pay for the hosting either way. We tell you which tier your requirements actually need before you commit to the platform.
Each document has a version per locale, linked so an editor can move between them and see what is still untranslated. Untranslated fields fall back to the default language on the site rather than rendering blank, which matters during the weeks when Arabic content is still being written.
Yes — the content is in a database you control and exports cleanly. That portability is a real argument for it over a hosted platform, and we structure the front end so it reads through a small layer rather than calling Strapi directly everywhere, which keeps a future move to a day of work.
Its own process, which can sit on the same server as everything else on a small project. It needs a Node runtime and a database, so shared cPanel hosting is out. For most projects that means one modest VPS running both the CMS and the front end.