The problem with SFTP and manual deploys
Deploying by dragging files over SFTP is how sites end up half-broken: a file gets missed, composer isn't run, a migration is forgotten, and the cache still serves the old bundle. There's no record of what shipped and no clean way to reproduce it. GitHub Deploy replaces that with a defined pipeline tied to your repository, so a release is the deterministic result of a commit plus a fixed set of steps — the same every time, by anyone on the team.
Your build steps, run consistently
A real deploy is more than copying files: dependencies must be installed, assets compiled, and database migrations applied in the right order. You define those steps once — for example composer install, an npm or asset build, and a migration command — and they run on every deploy against the exact commit being shipped. That kills the whole class of bugs where production behaves differently because someone ran the steps in a different order or skipped one under pressure.
Manual deploys and webhook auto-deploy
Different teams want different triggers. A cautious team keeps deploys manual, clicking deploy in the panel after review so a release is a deliberate act. A fast-moving team enables the webhook so every push to the production branch ships automatically, turning git push into a deploy. Both run the same pipeline; the only difference is what pulls the trigger, and you can start manual and switch on the webhook once you trust the flow.
Private repositories and secure tokens
Most real code is in private repositories, so the platform authenticates with a token you provide rather than requiring the code to be public. The token is stored as a secret and used only to clone at deploy time; it never appears in logs or the UI after it's saved, and because it's separate from your code you can rotate or revoke it independently. Webhook deliveries are verified with a signed secret so a random POST can't trigger a release.
Auto-purge closes the last gap
The most common post-deploy bug is a fresh release hidden behind a stale edge cache — new CSS or JS shipped, but visitors still load the old, cached bundle. GitHub Deploy purges the edge cache as part of the release, so the deploy isn't considered done until the cache reflects the new files. That removes the manual flush step people forget, and it means what you shipped is what visitors actually receive.
Repeatable delivery for teams and agencies
When every project deploys the same way, onboarding and handover stop being tribal knowledge. Deploy status, the last deploy time, and the configured steps are visible in the panel, so anyone can see whether the latest push made it to production and what ran. For agencies this means a standard delivery model across client projects, where handing a site to another developer doesn't require them to reverse-engineer a bespoke, undocumented deploy ritual.
How to deploy, step by step
Connect the repository and branch
In the panel open your app, go to GitHub Deploy, and enter the repository URL and the branch you deploy from — typically main or production. The branch you pick is the one that becomes live, so feature branches never ship by accident.
Authorize a private repository
If the repo is private, add a personal access or deploy token so the platform can clone it. The token is stored as a secret, used only to pull the code at deploy time, and can be revoked or rotated without touching your application.
Define the build and migration steps
Set the commands that turn a checkout into a running release — for a PHP app that's usually composer install --no-dev, a front-end asset build, and a database migration. These steps are saved with the app so every deploy runs the identical pipeline, not whatever someone remembers to type.
Choose manual or webhook auto-deploy
Deploy on demand with a button in the panel, or enable the webhook so a push to the connected branch triggers the deploy automatically. The webhook uses a signed secret, so only genuine pushes from your repository can start a release.
Ship, purge, and confirm
On deploy the platform pulls the branch, runs your steps, and activates the new release; the edge cache for changed assets is purged automatically so visitors aren't served stale files. The panel shows deploy status and the last deploy time so you can confirm the release is live.
Example scenarios
A push to main triggers composer install, an asset build, and migrations, then the release ships and the edge cache is purged automatically.
An agency connects a private GitHub repo with a scoped deploy token, keeping the code closed while the platform still pulls and deploys it.
A team keeps auto-deploy off and clicks deploy in the panel after code review, so every production release is a deliberate, logged action.
Frequently asked questions
Does GitHub Deploy build a Docker image, or deploy source code?
It deploys application source onto the platform runtime — it pulls your branch and runs your build and migration steps on the code itself. That's the natural fit for PHP and framework apps. If you specifically want a container image built and run, use Container Apps with a prebuilt image or Docker Compose Instant Deploy instead.
What exactly happens on a webhook push?
A push to the connected branch sends a signed webhook to the platform, which verifies the signature, clones or fetches that commit, runs your defined build and migration steps, activates the new release, and purges the edge cache. The panel then updates the deploy status and last-deploy time so you can confirm it landed.
How is my access token protected?
The token is stored as a secret and used only to clone the repository at deploy time. It isn't displayed after saving and doesn't appear in build logs, and because it lives separately from your code you can rotate or revoke it in GitHub without changing anything in the app.
Can I roll back if a deploy goes wrong?
Because deploys are tied to commits and defined steps, recovering is a matter of deploying a known-good commit — you point the deploy at the previous working commit or revert on the branch and let the pipeline ship it. Keeping deploys reproducible is exactly what makes going back reliable instead of a scramble.
Which branch goes live, and can I deploy from more than one?
You choose the branch to deploy from, typically main or a dedicated production branch, and only that branch ships — pushes to feature branches don't deploy. This keeps work-in-progress out of production while still letting you deploy the moment you merge to the release branch.
Does it work with GitLab or other Git hosts, or only GitHub?
The workflow is built around a Git repository URL, a branch, and a token, so it isn't limited to GitHub specifically — any repository you can reach with a URL and an access token fits the same model. GitHub is the common case, which is why it's named for it, but the mechanics are standard Git.