🪜
Staging first, then production.
PHP hosting with staging environments
PHP hosting with staging environments built in: an app holds as many environments as the project needs, each a complete, isolated setup with its own branch, components, variables and test domain.
Built with
Built what
Built how
fortrabbit is managed PHP hosting with staging environments built into the model: an app holds any number of environments, and each one is a complete, isolated hosting setup with its own PHP runtime, storage, MySQL, environment variables, SSH login and HTTPS test domain. Connected to GitHub, each environment maps to a branch, so a push to staging deploys staging and a push to main deploys production. Components are booked per environment and billed by the day, which lets staging run on the smallest sizes at €2.50 a month while production is sized for its traffic. Environments are stateful: uploads, sessions and the database belong to the environment and survive deployments, so production data reaches staging only when somebody syncs it down, with mysqldump and rsync over SSH. The API and the MCP server create a new environment as a copy of an existing one, components and settings included. Every new app starts with a seven-day trial without a credit card.
One app, a production and a staging environment
app: client-site
├── main ← production PHP MD · MySQL LG · 6 backups
├── staging ← staging PHP XS · MySQL XS · 1 backup
└── redesign ← temporary PHP XS · MySQL XS · 1 backup
Each line is a branch and an environment. Services run separated, so a load test on staging does not slow production, and a broken deploy on redesign leaves main serving. The staging environments feature page describes the isolation in more detail.
What stays separate per environment
- Components and their sizes, billed per environment
- Environment variables, PHP version and PHP settings
- Files, uploads, sessions and the database
- Domains, certificates and the test domain
- Deployment settings: branch, build commands, strategy
Runtime data is the hard part
A content editor publishes on production while a developer tests on staging with last month's database. That gap exists on every platform with stateful environments. The staging guide covers the usual set-ups and how to sync a database down. Most frameworks read the stage from an environment variable, which each environment sets on its own.
