Headless CMS hosting

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.

# 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 into the web space 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.