API backend hosting

The clients ship on their own schedule. The backend can't wait for them.

A PHP service that answers JSON, consumed by clients it doesn't control and can't deploy. No templates, no session cookies — only routes that take a request and return data. Deploys go by git push: the build runs Composer in a separate deploy container, and only the finished package is synced in. Migrations and console commands run over SSH.

# Work that isn't a response

Sending mail, generating exports, and calling third parties that time out have no business inside a request. The jobs component runs workers and cron jobs in a container isolated from the web layer, sharing the code base, database, and env vars — a webhook handler that writes a row and returns immediately survives a spike that a synchronous one won't. Jobs scale by memory and job count, separately from PHP.

Persistent connections aren't supported, so APIs that need to push do it by polling or by calling webhooks back out.

# Old versions don't leave on request

A mobile app in the wild pins the contract for as long as people postpone updates, and no deployment on this side changes that. Route prefixes and header negotiation cover the small breaks. For a hard one, a major version runs as its own environment: each environment tracks its own Git branch and books its own components, so v1 sits frozen on a small PHP plan while v2 settles beside it.

The same mechanism does duty before the break. A staging environment runs the next contract against a copy of the data, on a test domain with HTTPS from the first deploy — client developers integrate against a real URL instead of a mock.

# Why fortrabbit?

Deploys, SSH, cron jobs, and queue workers are the product here, not add-ons sold on top of it — a managed PHP platform still run by the people who built it. Push to deploy, keep the slow work in the jobs component, and scale PHP and workers apart. The API stays quick while the front ends multiply across app stores, CDNs, and hosts nobody here has to manage.