Auto-deploy from GitHub: ship on every git push
Turn on auto-deploy so Voroa builds and ships your app on every push to your branch, and learn how to switch it on or off for each service from its settings.
Auto-deploy connects your GitHub repository to your Voroa service so that every push to your branch triggers a new build and rollout — no manual steps.
How it works
When auto-deploy is on, pushing to the service’s branch on GitHub automatically starts a new deploy in Voroa. You can watch the build stream in the Deploys tab, and the deploy history records that it came from a push.
Only the branch configured for the service deploys. Pushes to other branches are ignored.
Auto-deploy follows the repository the service is set to build from. If you change that repository, pushes to the new one deploy the service and pushes to the old one are ignored.
Enable or disable auto-deploy
- Open the service and go to Settings.
- Find Automatic deploys.
- Toggle it On to deploy on every push, or Off to deploy only when you choose.
When auto-deploy is off, your service never redeploys on a push. You stay in control and can ship manually at any time using Manual Deploy → Deploy latest commit.
Several pushes in a row
If you push again while a build for the same branch was just started, Voroa does not run one build per commit. The pushes are grouped and one build runs for the latest commit, so the newest code always ends up live and no commit is silently lost.
Deploy only when certain files change
In a monorepo, or when you edit docs often, you may not want every push to rebuild the service. Build filters (under Settings, then Build & Deploy) decide which changed paths start a deploy. A push that only touches ignored paths is recorded but not built. See monorepo support and build filters.
Why a push did not deploy
Check these in order:
- Auto-deploy is off for the service. Turn on Automatic deploys in Settings.
- You pushed to a different branch. Only the branch set on the service deploys. Check it in branch and root directory.
- Build filters skipped it. The push changed only paths the service ignores.
- The repository is no longer connected. If GitHub access was removed or suspended for that repository, pushes stop reaching Voroa. Reconnect it from GitHub.
- A build limit was reached. Free build time or the build rate limit can hold a deploy back. The deploy history shows the reason.
Open the Deploys tab first: every push that reached Voroa leaves a row there, with its commit and status. See deploy history and logs.
Requirements
Auto-deploy needs the repository to be connected through GitHub. If the toggle is unavailable, connect GitHub first — see deploy from GitHub.
Frequently asked questions
Does auto-deploy work with pull requests?
A push to the service’s branch deploys the service. Pull requests do not deploy the main service; turn on pull request preview environments to get a separate live copy for each pull request.
Can I deploy without pushing a new commit?
Yes. Use Manual Deploy, then Deploy latest commit, or call a deploy hook from your own CI.
Can I undo a bad auto-deploy?
Yes. Roll back to an earlier deploy from the deploy history. See rollbacks.