GitHub

Sign-in and OAuth scopes#

There is no email/password registration — Sign in with GitHub is the only way in, and the first sign-in creates your account. The OAuth authorization screen requests four scopes:

After the OAuth exchange, the GitHub access token is stored AES-256-GCM encrypted and a deplo.ai JWT is issued for your session. Neither is ever returned by the API. See Authentication & Security for the full trust model.

Repository syncing#

deplo.ai keeps its own lightweight index of your repositories — name, default branch, visibility, language — so the dashboard and CLI can list and match them without hitting GitHub on every request. Syncing happens:

• Automatically on sign-in — every login refreshes the index from GitHub, paginated across all repos you own, collaborate on, or can access through an organization.
• On demand — the Sync button on Dashboard → Repositories, which calls POST /api/v1/repos/sync.
• On the CLI's first deploy — when deplo can't match your working directory's git remote to a known repo, it syncs from GitHub before matching again.

POST /api/v1/repos/sync
Authorization: Bearer <token>

{ "synced": 42 }

The repo list is cached for five minutes, and a sync busts the cache — so a repository created seconds ago appears as soon as you hit Sync. See the Repositories API for the endpoints.

Private repositories and the GitHub App#

OAuth sign-in covers your identity and public repositories. For private repositories deplo.ai additionally uses the deplo GitHub App: installing it grants repository access explicitly, per account or organization, with a repo-by-repo selection — which is both more precise and required for organizations that restrict OAuth app access. The dashboard prompts you to install it when a deploy needs it, and the CLI prints a hint pointing at Dashboard → Repositories → Configure access.

You can review or change the installation any time at github.com/settings/installations — including widening or narrowing which repositories it can see.

Webhooks and push-to-deploy#

During a deployment, deplo.ai registers a push webhook on the repository (this is what admin:repo_hook is for). Registration is best-effort and idempotent — if it fails, the deployment still succeeds, and if the hook already exists it's skipped. Once the hook is in place, every push triggers an automatic redeploy:

• GitHub delivers the push event to deplo.ai's webhook endpoint; the payload signature is verified with an HMAC-SHA256 shared secret before anything else happens.
• deplo.ai looks up the repository and creates a new deployment for the pushed branch.
• If a previous deployment of that repo and branch already has a detected stack and environment variables, the configuration is reused and the push goes straight to deploy — no re-analysis, no env prompts. The log shows “Auto-redeployment triggered by GitHub push — reusing previous configuration.”
• Otherwise the push runs the full pipeline from analysis, which may pause at WAITING_FOR_ENV if required variables are missing — see Environment Variables.

In practice: deploy once from the dashboard or CLI, and from then on git push is your deploy button. Existing Vercel projects and Render services are reused idempotently — see Deployments for the pipeline details.

Branch handling#

Deployments started from the dashboard or CLI always use the repository's default branch (usually main). Webhook-triggered redeploys use whichever branch was pushed, reusing the last configuration recorded for that branch. There is no branch picker in the UI today — deploying a non-default branch as a first deploy is not yet supported.

Revoking access#

Two things to revoke, both on GitHub's side:

• The OAuth authorization — GitHub → Settings → Applications → Authorized OAuth Apps → deplo.ai → Revoke. This invalidates the stored access token; sign-in, repo syncing, and analysis stop working until you sign in again.
• The GitHub App installation — github.com/settings/installations → deplo → Uninstall (or narrow its repository selection instead).