# Headless CMS hosting

Source: https://www.fortrabbit.com/use-cases/headless-cms
Created: 2026-07-20
Reviewed: 2026-07-20

> Host the back end of a decoupled CMS setup — Craft, Statamic or Drupal serving content over an API, with the front end deployed wherever it fits.


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.

## FAQ

### Is a headless CMS product offered here?

**No** — fortrabbit hosts the CMS that a team installs and controls — Craft, Statamic, Drupal, and other PHP applications. It is not an alternative to Contentful, Strapi, or Sanity. The content model, the plugins, and the upgrade schedule stay in the team's hands.

### Can the front end be hosted here too?

**Sometimes** — A PHP front end can run as a second app in the same account, sharing billing and access. A pre-rendered JavaScript front end is a different kind of workload and is usually deployed to a platform built for static output.

### How do editors preview unpublished content?

**Through the CMS** — Preview is handled by the CMS itself. Craft and Statamic both render a preview target against draft content, and that target can be the decoupled front end as long as it can be reached over HTTP and accepts a preview token.

### What happens to caching when an editor publishes?

**Invalidation** — The CMS fires an event on save. Whether that clears a cache key, purges a CDN path, or calls the front end's build hook is application logic. The CMS keeps its own cache on the file system or in MySQL; outgoing HTTPS requests handle the purge and the hook.

### Where do images and uploads live?

**In persistent storage** — Uploads go to the app's persistent storage — a real file system that survives deploys, because the default merge strategy overwrites what the deploy package contains and leaves everything else untouched. The asset filesystem abstractions in Craft, Statamic, and Drupal can also point at an external object store, but none is required.

---

- [Build commands](/features/build-commands)
- [Install guides](/guides)
- [Agent ready](/platform/ai-ready)