Git Repo Auth

Self-host · zero trust required

Don't trust our instance? Good. Run the same code as yours.

The hosted bridge holds one secret: our GitHub App's private key. If your threat model says no third party mints for your repos — correct response — deploy your own Worker with your own App and key. Identical code, identical flow; the only thing that changes is whose key signs the mints.

1

Create your GitHub App

Settings → Developer settings → GitHub Apps → New. Webhook off. Permissions: Contents RW, Pull requests RW, Workflows RW (optional — it's a CI-escalation trade; read the security model), Metadata R. Explicitly not Administration. Make it public if others should install it.

2

Enable user OAuth on the App

Set the Callback URL to https://<your-deployment>/callback, generate a client secret, note the Client ID.

3

Generate the private key

Paste it as-is when prompted — the worker auto-converts GitHub's PKCS#1 PEM to the PKCS#8 that WebCrypto needs. The key never transits chat in any form.

4

Configure, set secrets, deploy

Set GH_APP_SLUG in wrangler.jsonc and create your own KV namespace for OAUTH_KV. Then:

# secrets — never committed, never pasted in chat
wrangler secret put GH_APP_ID
wrangler secret put GH_APP_PRIVATE_KEY    # the PKCS#8 PEM
wrangler secret put GITHUB_CLIENT_ID
wrangler secret put GITHUB_CLIENT_SECRET

npm install && npm run deploy
5

Point your clients at it

Your connector URL is https://<your-deployment>/mcp — the same Settings → Connectors flow as the hosted version, except every link in the chain is yours. Keep any existing PAT until the first real token mints; retiring the fallback before validating the replacement is how lockouts happen.

Source, security model, and the project journal: github.com/klappy/git-repo-auth-mcp. The blast-radius section of the README is written for exactly your threat model — read it before trusting anyone's instance, including ours.