Cookies ahead

Our support chat tool "Intercom" would like to collect some more data on you. See the related link for more details.

Docs

Examples

These examples show the costs for different real life setups including apps with multiple environments and different software stacks.

Docs

fortrabbit / use cases

📰

Publish often, read often.

Content site hosting

Editors publish, visitors read. One application does both.

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 — a database, or in Kirby's case a folder of text files, on one side, templates on the other, a request in between.

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. The backup component snapshots the whole environment state, uploads and database included.

An honest account.

Different by design

A platform purpose-built for PHP. More than the sum of its parts.

Pay in arrears

Daily prorated, post-paid billing. No upfront payment, no yearly commitment.

Modular pricing

Pay per component and scale each one from xs to 2xl on its own.

No dark patterns

No vendor lock-in, no upselling, no misleading messages.

Humans in support

Eye-level developer chat over the support bubble. No sales calls.

Developer-first

Git-push deploy, SSH access, bring your own code. No 1-click bloat.

Managed platform

A hardened, service-oriented PHP stack. Deploy code, skip the server admin.

Frequently asked

Does a content site need a CDN in front of it?
Usually not

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

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

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

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

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.

#

What customers say

As a design and development studio, managing and maintaining servers used to take a big chunk of our time, especially when things went wrong or major updates were needed. Passing that responsibility to fortrabbit, who are absolute experts and have a specialist team, was a game changer. The service is faultlessly stable, support is always fantastic & prompt and it scales with the click of a button. The whole experience is so scarily smooth! The time they have saved us could not be more valuable.

Josh Attwood

Josh Attwood

Creative director at Josh Attwood Studio

2026 — Direct feedback

Developer-first web hosting with user-centered first-rate documentation and powerful dashboard - and real human, distinctively insightful, support too. We first had a go in 2013, never looked back since (and they are even better).

D

Dixens

Developer

2026 — Direct feedback

Thanks for the great service, I so prefer this to spinning up my own Linux box every time.

MB

Matt Bloomfield

2025 — Customer support

More