Connect GitHub
Connecting an app to a GitHub repository turns “deploy” into “merge to a branch.” Watasu watches the branch and ships a release for every commit.
When this is the right setup
Section titled “When this is the right setup”- one app maps to one branch (typical:
main→ production app,develop→ staging app) - you want pushes to trigger deploys without anyone running
git push watasu - you’re not yet using staged promotions (for that, see Pipelines and Promotions)
What you get
Section titled “What you get”- automatic deploys on branch push
- optional gating on GitHub status checks (CI must pass before deploy)
- a clear deploy history tied to commits in your repo
Auto-deploy on a branch
Section titled “Auto-deploy on a branch”Once connected, the app deploys every commit on the watched branch. The build, release, and rollout happen the same way they would for git push watasu — just kicked off from GitHub.
Required checks
Section titled “Required checks”If your team uses GitHub status checks (CI test runs, lint, security scans), Watasu can hold deploys until required checks pass. That keeps “merged to main” and “deployed to production” from drifting apart.
Configure required checks at the repository level in GitHub; Watasu respects them.
Auto-deploy vs. pipelines
Section titled “Auto-deploy vs. pipelines”Auto-deploy on its own works well for a single app or a small team where every commit goes straight to its environment. When you start needing:
- a separate staging stage that gates production
- promotion of an already-built artifact from staging to production
- pull-request preview environments
…that’s when you reach for Pipelines and Promotions and Review Apps.
- start with
main→ production, see how it feels for a week before adding more - turn on required checks before turning on auto-deploy
- if you don’t trust your CI yet, the manual
git push watasu mainpath is still there