That is how can Marsa Operator use Marsa to authenticate GitHub so Marsa could pull his code.

Decision (2026-06-07) — see AgDR-0005

This issue is GitHub repo access (pull/clone code, webhooks for push-to-deploy). It is independent of the login/IdP choice (#22 / AgDR-0004) and is permanent — it survives the v0.1 → v0.2 Zitadel migration unchanged.

v0.1 scope (this milestone)

• Per-install GitHub App, created via the GitHub App Manifest flow. A single central App can't serve self-hosted installs on arbitrary operator-chosen domains (webhook/callback URLs are fixed at registration), so each install provisions its own.
• One App serves both this issue (installation tokens → clone/webhook) and Marsa Auth #22 (its user-OAuth flow → login).
• Operator setup ≈ 2 clicks: manifest "Create App" (pre-filled for their domain) → "Install" on chosen repos. Marsa auto-stores App id / private key / client secret / webhook secret from the conversion callback. Runs in the first-run wizard after domain + TLS are set.
• Installation tokens (App JWT via private key → ~1 h installation token) minted on demand and cached.

Webhook reachability

• Satisfied by the operator's publicly-resolvable domain + public-ingress TLS (e.g. demo.marsa.cc). Requirement is public DNS + reachable ingress + TLS, not TLS alone.
• Air-gapped / LAN-only installs (no public DNS) would need a polling fallback — out of scope for v0.1, noted.

OIDC/SSO note

• This GitHub App integration is not part of the SSO story; SSO (other services authenticating) is handled by the v0.2 Zitadel IdP. The deploy App stays as-is regardless.

Developers

• Each dev creates a throwaway test GitHub App (~15 min) + a public tunnel (ngrok/cloudflared) for local webhook delivery.

Full reasoning + options table: AgDR-0005 (GitHub App integration model).