For the boss

Hosting requests rarely start with the person who signs. The developers pick a platform, make their case, and then somebody with budget responsibility has to approve a vendor they may never have heard of. This page is for that somebody. The developer arguments live elsewhere on this site — what follows are the procurement answers: who runs this company, what the real exposure is, where data sits, how the cost behaves over time, and what leaving would look like.

# Will this vendor exist in five years

That is the first honest question about any small vendor, so it goes first. fortrabbit has operated since 2012, owned and run by the same independent company — a GmbH registered in Berlin, with roots in internet services going back to 2004. It was the first European platform as a service built specifically for PHP, and it still does that one thing. The company is bootstrapped: there are no investors to satisfy, so there is no pressure to inflate growth, sell the business or raise prices to meet a valuation. The company history is published including the slow years — a fourteen-year-old business that documents its own plateaus carries a different risk profile than a funded startup whose hosting product must grow or die.

# The books are open

Most vendors ask to be trusted on pricing; this one shows the ledger. The published cost breakdown states where revenue goes: 44% people, 33% infrastructure, 10% sub-processors, 2% marketing, 1% donations, 1% irregular expenses — and a 4% profit margin. Two of those numbers matter for a buying decision. The 2% marketing share means the price funds operations rather than customer acquisition. And the 4% margin means the service is priced to sustain itself, not to maximize a valuation — a company living on 4% cannot afford to lose long-term customers to short-term price games.

# The exposure, in writing

The uptime commitment is a written service level agreement, not a marketing figure: 99.5% general uptime, with service credits proportional to actual downtime and capped at the monthly fee. The number is set conservatively and the conditions are published in full — including the standard limitation that no hosting provider accepts liability for consequential damages, which is better read now than discovered later. Underneath, apps run on AWS infrastructure in isolated environments, so one busy application cannot starve another. What does not exist: custom SLAs. The terms are the same for every customer, which is part of why the price is what it is.

# Where the data sits, and who else touches it

Each app runs in a region chosen at creation — EU (Ireland) or US — and account and billing data is stored in Ireland. The contracting party is a German company, contracts are governed by German and European law, and the GDPR data processing agreement is part of the terms of service: it applies automatically, with nothing separate to sign. Every sub-processor that handles data is listed publicly and assessed for GDPR compliance. One caveat belongs here rather than in the fine print: this is not a sovereign cloud. The infrastructure is AWS and several sub-processors are US companies, so the US CLOUD Act can apply. What is on offer is transparency about exactly that — the full vendor-assessment picture sits on the trust page.

# How the cost moves

Billing is component based and post-paid: an app books the resources it needs, usage is billed pro-rated by the day, and the invoice arrives after the period it covers. There are no per-seat licenses and no feature tiers — adding people, teams or payment methods never changes the bill, so cost follows the workload rather than the org chart. Spending can be capped: autoscaling is optional, and with a fixed plan an app cannot quietly outgrow what was approved for it. There is no minimum term and nothing is paid upfront. The smallest possible setup starts at €2.50 per month; current numbers and worked examples live under pricing and pricing details.

# Nothing proprietary to be trapped by

Lock-in risk is a function of proprietary surface, and there is little of it here. The stack is standard PHP, MySQL, Git and Composer — no vendor-specific framework, no proprietary database, no installer format that exists only on this platform. An application that runs here runs on any comparable host: the code lives in the team's own Git repository, the database exports with standard tools, and the domain points wherever DNS says. Cancellation works from the dashboard with immediate effect and no termination fee; billing stops the same day. The same openness applies on the way in — migrations are not performed on anyone's behalf, as a stated principle, so the developers who move an application here will be the ones who understand where everything lives.

# Accountability when something breaks

Responsibility is split along a named line: we operate and secure the infrastructure and the stack; the application code on top stays with the developers who wrote it. That line is policy, not fine print: when something fails, the layer says whose problem it is. Support runs through chat, answered by the same small team that operates the platform — there is no first-level call center to get past. The median first response is under two hours during business hours (CET), and most cases are resolved within a day. Infrastructure failures are not support tickets: monitoring runs around the clock, with humans on call behind it, independent of chat hours.

# Why not the provider nobody gets fired for choosing

The safe answer to any hosting decision is a hyperscaler, and the comparison is fair to raise — fortrabbit itself runs on AWS. The question is who operates the platform on top. Using AWS directly means someone in-house owns a hundred-service console, the cost spreadsheet, the patching and the 3 am pages — capability that is bought as headcount. What fortrabbit sells is that operations layer as a service: managed middleware on AWS, priced so the honest comparison is not against the AWS invoice, but against the AWS invoice plus the fraction of an engineer who tends it.

# What is not on offer

A procurement checklist will surface these anyway, so here they are up front. Nobody here answers a phone, and there is no premium support tier to buy. There are no custom contracts, negotiated terms or individual SLAs — the service is standardized self-service, and we do not keep a legal team to redline vendor agreements. fortrabbit holds no SOC 2 report and no own ISO 27001 certificate (the AWS infrastructure underneath is certified); there is no HIPAA BAA, so regulated health data is out of scope. There is no root access, because this is a managed platform, not a rented server. Any of these can be a legitimate deal-breaker — better found on this page than after signature; the compliance page answers the usual questionnaire items in the same spirit. For everything else, the cheapest due diligence is the free trial: seven days, full feature access, no credit card — run by the developers who started this conversation.