Startup hosting

A startup before product-market fit has one engineering priority: find out whether anyone wants the product. Every hour that goes into provisioning servers, tuning deploy scripts or reacting to a disk-full alert is taken from that question — and it burns runway all the same. At fortrabbit the platform layer is our job and the product is the team's, a split we have operated since 2012 for the frameworks startups build on: Laravel, Symfony, Tempest and more. And because a hosting pitch should survive contact with growth, this page also says plainly where the platform stops fitting.

# The DevOps hire that can wait

Hiring an infrastructure engineer before revenue means paying one of the most expensive salaries on the market to keep servers alive for users who may not exist yet. The usual workaround — the founding developer runs operations on the side — costs more than it looks, because infrastructure work is interrupt-driven: it arrives as kernel advisories, full disks and expiring certificates, and it fragments exactly the focused weeks an unshipped product needs.

The division of labor here is explicit. We operate the platform — operating system, web server, PHP runtime, MySQL — and keep it patched and monitored around the clock; the team stays responsible for the software it writes and deploys. The deploy pipeline comes with the platform instead of being built by hire number one: connect the repo through the GitHub integration, push a branch, and dependencies are installed and artifacts built on our side, with settings that allow deployments without downtime. A first technical hire inherits working infrastructure and gets to work on the product.

# Burn that follows usage, not a contract

A hosting line in a burn table should move with product usage, not with a contract date. Billing is component-based and post-paid, pro-rated with a one-day minimum: PHP, traffic and storage are required, while MySQL, the jobs component and backups are booked only where the product needs them, each sized in its own small steps. The smallest possible combination starts at €2.50 per month, so a landing page validating an idea is not priced for the success case. Nothing is paid upfront and there is no minimum term — the hosting number in this month's burn is what the product consumed this month.

Two things never show up in that number. Collaboration carries no charge — teams, invited people and payment methods are free, so headcount growth does not leak into the hosting bill. And there are no feature tiers to be pushed up from: cost follows load and data, nothing is gated behind a bigger plan. For a hard budget line, autoscaling can be switched off per environment, trading elasticity for a fixed price. Worked examples live on the pricing page and in the pricing details.

# An experiment should be cheap to end

Most startup code is written to be thrown away — that is what validated learning means in practice. Hosting rarely cooperates: a test server set up for a killed feature tends to keep running because nobody remembers why it exists, and a prepaid plan keeps billing for a pivot that already happened.

Environments here map to that workflow. Each app carries any number of environments, every one an isolated hosting setup with its own Git branch, own domains and individually sized components. A risky feature branch gets a small environment for the days it is under review, a staging environment mirrors production for the release candidate, and the multi-staging guide covers the patterns. Deleting an environment removes it within minutes, files and database included — and with daily pro-rated billing, an environment deleted on Tuesday is off the invoice from Wednesday.

The same holds one level up. Every new app begins with a free trial: seven days, all components available in all sizes, no credit card required. A proof of concept can be built, demoed to an investor and discarded without ever producing an invoice — and the next idea starts a fresh trial.

# Traction without re-platforming

Elsewhere, growth tends to mean a bigger box and a maintenance window. Here it is a plan change: each component scales individually from the dashboard, takes effect right away, and nothing moves. Traffic, storage and MySQL autoscale by default — a spike books the next plan up, and the booking steps back down once the wave passes. PHP does not autoscale, deliberately, because PHP load patterns are too individual for a safe automatic signal; it is scaled by hand, from XS up to 2XL.

Equally important is the direction of scaling. Components move independently, so customer growth that needs more PHP processes does not force a bigger database, and the other way around — spend follows the actual bottleneck. What a subscription product looks like on this platform in practice — billing runs in workers, one database per environment, polling instead of push — is covered on the SaaS use case page.

One choice does not scale later: the region. It is picked per app — EU (Ireland) or US — and cannot be changed afterwards, so it should follow where the first paying users will be.

# Where the ceiling is

A platform pitch that claims to fit forever is lying to somebody. This is a managed PHP platform, and its shape has edges. There is no root shell and no way to install system software — anything beyond PHP, from FFmpeg to Node, is out. There is no Redis component; in-process caching falls to OPcache and APC, while queues run through the database with workers in the jobs component. Persistent connections are not supported, so WebSocket features — live dashboards, collaborative editing, chat — need polling or a third-party service. And an app lives in exactly one region.

For the stretch between first deploy and serious scale, these edges rarely bind: the XS and S PHP plans already cover most ordinary workloads, and the range tops out at eight parallel PHP processes on the largest plan. But a product whose roadmap depends on Redis-backed realtime features, kernel-level tuning or multi-region infrastructure has outgrown this platform — and will by then usually have raised the team that runs raw cloud infrastructure. Reaching that ceiling is the good outcome. The full list of edges is on no X and in the limits docs.

# Answers for the due-diligence deck

At some point an investor, an accelerator checklist or a first enterprise customer asks about vendor risk, and "a PaaS we found" is a weak answer. The facts here are public. fortrabbit has operated since 2012 as the first European platform as a service built specifically for PHP — bootstrapped, and still owned by the same independent Berlin company whose history goes back to 2004. Apps run on AWS infrastructure, backed by a 99.5% uptime SLA with defined service credits. And the business is profitable rather than growth-funded: the cost breakdown is published, down to the 4% margin. A vendor that does not depend on its next funding round is one less dependency that can fail at the same time as everything else.

The exit path is equally checkable. The stack is standard PHP, MySQL and Git: the code already lives in the team's own repository, the database leaves as a plain mysqldump, files leave over SFTP, and there is no minimum contract term to buy out of. A dependency that can be ended in an afternoon barely counts as one.

# When the team arrives

The first hires change what the account has to do, not where the app runs. Collaboration is built in and free of charge — the mechanics of teams, roles and per-app access for contractors are on the agency page, the underlying model under collaborate. And if the exit is the happy one — an acquisition, or the product moving in-house somewhere — ownership of an app changes hands without the app moving. What was founder-built becomes team-run by granting access, not by re-hosting.