# PHP hosting with git push deploy Source: https://www.fortrabbit.com/php-hosting/with-git-push-deploy Published: 2026-10-01 Reviewed: 2026-10-01 > Deploy PHP to fortrabbit by pushing to GitHub. Composer and npm run in a separate build service, the release is atomic, uploads survive. GitLab, Bitbucket and Codeberg deploy over CI. fortrabbit is managed PHP hosting with git push deploy as the default. The fortrabbit GitHub App connects a repository to an app and a branch to each environment; a push to the branch starts a deployment on fortrabbit, with no GitHub Actions minutes involved. The build runs in a separate deploy service with the same PHP version as the environment: `composer install`, then an npm build when the project has one, both pre-configured by the software template for Laravel, Craft CMS, Statamic, Kirby, WordPress and others. If a build step fails, the deployment stops and the previous release keeps serving. Post-deploy commands such as migrations and cache clears run on the web runtime afterwards. Storage is persistent: a deploy overwrites code and leaves uploads, sessions and the database untouched, or replaces the whole web space when the project is built for immutable releases. Repositories on GitLab, Bitbucket or Codeberg deploy through their own CI pipelines over SSH deploy keys. Every new app starts with a seven-day trial. ## The git push deploy pipeline ```raw 1 Local 2 Git provider 3 fortrabbit 4 environment ┌─────┐ ┌────────────┐ ┌──────────────┐ ┌──────────────┐ │ Git ├───▶ Git repo ├───▶ Deployment ├───▶ web space │ └─────┘ └────────────┘ └──────────────┘ └──────────────┘ ``` The deploy service is its own container, so a heavy `npm run build` does not take memory from visitors. Dependencies are cached between deploys. Source directory, exclude patterns and [build commands](/features/build-commands) are set in the dashboard or in a [deploy file](https://docs.fortrabbit.com/platform/deployment/deploy-file) in the repository. ## Two deployment strategies - Merge: newer files replace older ones, new files are added, nothing else is touched. The default, and the right one for a CMS whose editors upload files. - Replace: the web space is wiped and rebuilt from the deploy package, except for the paths in the exclude patterns. Immutable releases for twelve-factor style apps. ## Git syncs up only Code goes up through Git. Content comes down through SSH and SFTP. A file uploaded over SFTP never shows up in the repository, which keeps the repository free of binaries and runtime data. The [deployment intro](https://docs.fortrabbit.com/platform/deployment) draws the full picture, including what the storage holds after a deploy. The [GitHub integration page](/features/github-integration) covers installing the app and connecting a repository. ## FAQ ### Are GitHub Actions required? **No** — The fortrabbit GitHub App connects to the repository directly. The build runs on fortrabbit, so no Actions minutes are spent. Actions can still be used as an alternative trigger, with a deploy key. ### What happens when composer install fails? **Nothing goes live** — The deployment is aborted and the previous release keeps serving. The deploy log in the dashboard shows the failing step. ### Do deploys delete uploads? **No** — The default merge strategy overwrites files from the build and leaves everything else alone, so uploads, transforms and sessions persist. The replace strategy wipes the web space first and keeps only the paths named in the exclude patterns. --- - [GitHub integration](/features/github-integration) - [Build commands](/features/build-commands) - [Git hosting](/integrations/git-providers)