Connect a repo
Connecting a repo is a one-time setup; every deploy after that follows the same pipeline.
Connect
Section titled “Connect”Install the Ravel GitHub App and choose a repo and branch. This is a GitHub App installation with signed webhooks, not a personal OAuth token — access can be scoped and revoked independently of any one person’s account.
Every deploy runs the same four stages
Section titled “Every deploy runs the same four stages”fetch → build → env-check → activate
- Fetch — the target commit is checked out into an isolated worktree, never your live checkout.
- Build — dependencies install if they’ve changed.
- Env-check — the same validation
ravel validateruns locally, plus a secret scan: committed.envfiles or high-confidence credential patterns (API keys, private key blocks) block the deploy outright, before anything activates. - Activate — the worker comes up on the new commit. A config-only change hot-reloads the running worker; a change to dependencies or secrets restarts it. Either way, the platform classifies which one automatically — you don’t declare it.
You can watch all four stages live from the console, and every deploy’s log is kept.
Health gate and automatic rollback
Section titled “Health gate and automatic rollback”After activation, the platform holds the worker in a probation window and waits for it to report healthy. If it doesn’t, the checkout is rolled back to the last known-good commit and the worker reboots on that — automatically, without a person needing to notice and intervene. A bad push can’t take a running team down.
Redeploy
Section titled “Redeploy”git pushA push to the connected branch fires the webhook, and the same fetch → build → env-check → activate pipeline runs again. You can also deploy an explicit historical commit rather than only ever the latest push.