Deploy from GitHub: How Push-to-Deploy Works, Step by Step

To deploy from GitHub means your live app follows your repository. You push a commit, and a few minutes later that commit is what your users see. No FTP, no SSH, no manual restart. This post walks through what happens between the push and the live URL, so you know what to expect and where to look when something goes wrong.

The steps from a git push to a live release: connect, build, start, switch traffic

Step 1: connect the repository

You install the platform’s GitHub app on the repositories you choose. The platform can then read those repositories, and only those. On Voroa, your code stays private. GitHub’s own docs explain how GitHub Apps get repository access.

Step 2: a push starts a build

Which branch deploys

You pick one branch for the service, usually main. When auto-deploy is on, a push to that branch starts a build. A push to another branch does not. You can change the branch or the folder later in branch and root directory.

What the build does

The build installs your dependencies and runs your build command. If you use a Dockerfile, it builds the image from that instead.

If the build fails

The live app does not change. The previous release keeps serving, and the build log shows the error. Fix it, push again, and a new build starts.

Step 3: the new release starts

The new release starts next to the old one. When it is ready, traffic moves to it, and then the old one stops. With a health check set, traffic moves only once the new release answers, so users do not hit a moment when nothing is running.

Step 4: roll back if needed

Every release is kept in the deploy history. If the new one misbehaves, roll back to the previous version, then fix the code and push again. Rollback needs at least one earlier deploy.

Preview a change before it goes live

A pull request can get its own temporary copy of the app, so a teammate can check the change on a real URL before it merges. See preview environments for how it works and what it costs.

Good habits for push-to-deploy

Protect the deploy branch. Merge through pull requests so every live commit was reviewed.
Keep secrets out of Git. Use environment variables; a push should never carry a key.
Commit lockfiles. Every build then installs the same packages.
Add a health route. A quick /health check makes a broken release obvious at once.