# CMS hosting Source: https://www.fortrabbit.com/use-cases/cms-hosting Created: 2026-07-20 Reviewed: 2026-07-27 > CMS hosting for editor-driven websites — flatfile like Kirby and Statamic, or database-driven like WordPress and Craft. Page caching, persistent storage, backups. **In today's web, everybody is headless. But remember the basics.** A CMS that renders its own pages: editors publish, visitors read, and the HTML arrives finished. It's stupid simple, and it's what PHP was built for. ## CMS flavors **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. That's the LAMP stack. Both are supported by fortrabbit. ### Flatfile 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. ### Database-driven 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. ## Classic or headless Every CMS here can also run headless. Craft and Statamic ship GraphQL and REST layers, Drupal carries JSON:API in core, and WordPress and TYPO3 serve content over an API too. The same PHP app either renders its own pages or answers an API request — the components underneath stay the same. Classic rendering is the default, and the simpler path: one deploy, finished HTML, nothing between the editor and the visitor. Headless splits the site into a content back end and a separate front end — a different shape, with its own reasons and trade-offs. For the decoupled setup — where the back end runs and how the front end connects — see [Headless CMS hosting](/use-cases/headless-cms-hosting). ## Why fortrabbit? fortrabbit has backed old, boring tech like PHP and MySQL since back when it was still cool — and still runs it as the main event, not a legacy checkbox. Push to deploy, keep uploads in persistent storage, and let the page cache carry the readers. We know this stack, and we host it like we mean it. ## 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](/workflows/agentic-engineering)