Privacy
What we store, and what we refuse to.
Last updated June 2026.
Source code is never persisted
The hosted control plane does not store your code. When a review runs, the CLI fetches the pull-request diff with a short-lived installation token, sends it to the model endpoint configured for your organization, and exits. The diff lives in process memory for the duration of the review and is gone with the process. There is no code cache, no embedding index, and no repository clone on our infrastructure.
What is stored
- Review envelopes: the JSON verdict of each review — summary, findings (file path, line number, severity, confidence, title, body), token counts, model id, and commit SHAs. Findings quote at most the few words needed to identify the issue.
- Account data: your GitHub user id, login, name, email, and avatar, provided during OAuth sign-in.
- Installation metadata: which repositories the App is installed on, by id and name.
- Usage events: prompt and completion token counts per review, for the dashboard and (post-beta) billing.
- Webhook delivery ids, kept for deduplication.
Envelope retention
Envelopes are retained while your organization has an account, both because they power the dashboard and because incremental re-review uses the previous envelope as its baseline. Deleting your organization deletes its envelopes, usage events, and settings. Uninstalling the GitHub App deletes the installation and its repository records.
Bring-your-own API keys
Organization LLM keys are sealed with AES-256-GCM before they reach the database and are decrypted only inside the worker, at the moment a review starts. The settings form is write-only: a stored key can be replaced or removed, never displayed. Keys are never logged and never leave the worker except as the Authorization header to the endpoint you configured.
Tokens and credentials
GitHub installation tokens are minted on demand, held in memory only, and expire within an hour. The GitHub App private key is provided via environment configuration and is never written to the database or to logs.
Subprocessors
- GitHub — source forge and OAuth identity: webhooks, check-runs, review comments, sign-in.
- Your configured model provider — receives the diff for the duration of a model call. With a BYO key this is your own provider relationship under your own data terms. The default for orgs without a key is OpenRouter, which is a router: it forwards the request to a downstream model provider, so the diff transits OpenRouter and then that provider. For sensitive code we recommend a BYO key pointed directly at your chosen provider, or self-hosting (below).
- Fly.io — application hosting: runs the web control plane and the review worker.
- Neon — managed PostgreSQL: stores accounts, installations, and review envelopes.
There is no analytics or tracking subprocessor. The site sets one cookie, the session cookie, only after sign-in.
Where data is processed (residency)
For the hosted service, application hosting runs on Fly.io in the London region (lhr) and the managed database (Neon) runs in a European region, so your account data and review envelopes are processed and stored in the UK/EU. Two things sit outside that boundary by design: when your org uses a BYO model key, diffs go to whatever provider and region you configure; and a self-hosted deployment keeps all data on your own infrastructure, wherever you run it. We make no SOC 2 or ISO certification claim.
Self-hosted
Self-hosted deployments send nothing to us. No telemetry, no license pings, no update checks. Your envelopes stay in your Postgres.
Contact
Privacy questions: [email protected]. Security reports: see security.txt.