# CMS hosting Source: https://www.fortrabbit.com/use-cases/cms Created: 2026-07-20 Reviewed: 2026-07-21 > CMS hosting for editor-driven websites — flatfile like Kirby and Statamic, or database-driven like WordPress and Craft. Page caching, persistent storage, backups. A CMS that renders its own pages: editors publish, visitors read, and the HTML arrives finished. It's the most common thing on the web, and it's the workload PHP was built for — content on one side, templates on the other, a request in between. ## Flatfile or database-driven Where the content lives splits the field in two. Flatfile CMSes like Kirby and Statamic keep entries as text files in folders; database-driven ones like WordPress, Craft CMS and TYPO3 keep them in MySQL. Both are ordinary PHP applications here — the difference is which components an environment books. A flatfile site runs on the PHP and storage components alone. The content folder is runtime data: editors change it on the server, so it belongs in persistent storage rather than the deploy package — the deploy sync only replaces what the package contains and leaves everything else in place. Teams that version content in git instead route edits through deploys; both setups work, but mixing them silently overwrites one side. A database-driven site adds the MySQL component for entries and settings, while uploads still land in storage. The backup component snapshots both together, so a restore point always holds a matching database and media library. ## Reads and writes pull in opposite directions A handful of editors write; everybody else reads. With a page cache doing its job, most requests are cache hits rather than full renders, so the PHP component is sized for the editors and the cache misses, not for the traffic graph. In practice the XS and S plans cover most normal websites, with 256 MB PHP memory as a workable starting point for WordPress and Kirby. ## Uploads outgrow everything else Text stays small for years; images and PDFs don't. Uploads live on the storage component, a persistent file system that survives deploys — each release replaces the code directory while runtime data stays in place. Storage is one of the autoscaling components: plans grow and shrink with measured usage, aggregated daily for billing. Components are booked individually and billed pro-rated, post-paid, by the day, so a site that grows for a season and settles again isn't stuck with the plan it needed in October. ## FAQ ### Is a database required? **Not for flatfile** — Kirby and Statamic store content as files, so an environment runs on the PHP and storage components alone — no MySQL component to book or maintain. WordPress, Craft and TYPO3 expect MySQL; the component is added per environment and billed by the day like everything else. ### Does a content site need a CDN in front of it? **Usually not** — A site with a working page cache and an audience in one region is served fine from the environment itself. A CDN starts paying off when the audience spans continents or large media files dominate the response weight — it is an addition, not a prerequisite. ### Where do editor uploads go? **Persistent storage** — The storage component is a persistent file system. Deploys replace the code directory; runtime data like uploads stays — so a media library survives every release without an external bucket. With autoscaling enabled, larger and smaller storage plans are booked automatically based on measured usage. ### Do scheduled posts publish on time? **Via cron job** — A well-cached site delivers few requests to PHP, so publish-on-visit schedulers like WP-Cron drift. The jobs component runs real cron jobs in dedicated back-end PHP processes, isolated from the web front-end. ### Who upgrades the CMS? **The developer does** — Responsibilities split cleanly: we run the platform, and everything installed on it belongs to whoever deploys it. No CMS version, plugin or Composer dependency is ever touched from our side — an unannounced change to a running site would be worse than an outdated one. An upgrade is a Composer change plus migrations, shipped with a git push like any other release. Trying it on a second environment with a copy of the database first is the usual approach, and components are billed by the day, so that costs days rather than a month. ### Is site migration handled by fortrabbit? **No** — Migration is not offered as a service — users stay in control of their hosting. Moving a site means deploying the code base with git push, importing the database, and copying the media library into persistent storage over SFTP or rsync. The docs cover each step, and support answers questions about the platform. --- - [Backups](/features/backups) - [Developer support](/benefits/get-support) - [Agent ready](/platform/ai-ready)