🧩
Content here. Pixels elsewhere.
Headless CMS hosting
Decoupled means two halves — this is where the half that owns the content runs. Host your headless CMS on fortrabbit.
Built with
Built by
Built how
Features
The front end will be rewritten. The content won't.
A decoupled setup splits one site into two deployable things, joined by an API and nothing else. This page is about the half that owns the content: a PHP application with a database, an asset store, and an admin interface. Craft and Statamic ship GraphQL and REST layers for exactly this; Drupal carries JSON:API in core. For the undecoupled version — one engine rendering its own pages — see CMS hosting.
Build traffic, not visitor traffic
A decoupled CMS gets very little traffic. Editors log in during working hours, and the front end queries the API — continuously if it renders on request, or in bursts if it pre-renders at build time.
That build is the surprising part. A full pre-render walks every entry, so one build can fire more API requests in a few minutes than the rest of the day combined. Sizing for the average misses it entirely; what absorbs the burst is the CMS response cache, since most entries didn't change between builds.
The back end is the half that lasts
Front ends get rewritten every couple of years. The content model, the editorial workflow, and a decade of uploaded assets are expensive to move and cheap to keep, so hosting the CMS somewhere that doesn't assume it also serves the public site is the point.
The CMS deploys like any PHP app here: git push, Composer in the build, then the deploy package syncs in without deleting the uploads already there. fortrabbit hosts the PHP half; a pre-rendered JavaScript front end is a different workload and belongs on a host built for static output.
Why fortrabbit?
PHP and MySQL as the main event, not as a compatibility mode — that is all fortrabbit has ever done, since before headless was a word for it. Managed, PHP-first, bootstrapped, and unlikely to discover a more fashionable core business. Deploy the CMS with a push, let the response cache absorb the build-time storms, and keep a decade of assets in persistent storage while the front end moves to whatever suits it this year.
Trust
An honest account.
