Self-hosting
The same orchestrator, engine and sandbox we run, deployed inside your boundary against your own GitHub App and your own model keys. This page describes what that actually costs you to operate.
Status
Self-hosting is an enterprise-tier deployment and is not generally available yet. The architecture above is what ships; the images and the Helm chart are published when the tier opens, alongside the deployment guide. We would rather say "not yet" here than sell an install that does not exist.
Who should self-host
Most teams should not. The hosted service is the same software with none of the operational burden below, and the isolation boundary is the same one we would ship you. Self-hosting is the right answer when one of these is true:
- Source code may not leave your network or your cloud account, as a matter of policy rather than preference.
- You are on GitHub Enterprise Server and it is not reachable from the public internet.
- You already hold a model provider contract with terms — retention, region, residency — that you need this workload to fall under.
- You are in a regulated environment where a subprocessor list is a procurement obstacle regardless of what is on it.
Self-hosting is an enterprise-tier entitlement (selfHosted: true in the entitlement table). It is not a way to run the product without paying for it — the open-source plan is that, and it is free and hosted.
What you run
| Component | Role | What you take on |
|---|---|---|
| Orchestrator | Receives GitHub webhooks, admits or rejects work, runs the review pipeline, posts the review. | One stateless service behind TLS with a publicly reachable webhook path. Horizontal scaling is a replica count. |
| Postgres 15+ | Reviews, findings, fingerprints, installation state, and the learnings vector index. | Backups and point-in-time recovery are yours. The schema ships as versioned migrations run at deploy. |
| Sandbox runtime | Per-review isolated instance that checks out the repository and runs analysers. | The heaviest piece. Needs a runtime that gives you real isolation and a default-deny egress policy — Firecracker, gVisor, or a dedicated node pool with a network policy. A plain Docker socket is not sufficient isolation for running untrusted code. |
| Object storage | Encrypted git bundles used to seed sandboxes, and stored review traces. | Any S3-compatible bucket. Lifecycle expiry is a bucket policy you set. |
| Model access | The find, verify and summary passes. | Your own provider keys, or a compatible gateway. Bring-your-own-key is the point of self-hosting for most teams: prompts never leave your contractual boundary. |
| GitHub App | Identity and permissions against your GitHub or GitHub Enterprise Server instance. | You register and own the app, so you own the private key and the permission set. Nothing is shared with us. |
| Key managementoptional | Holds the GitHub App signing key so it is never in an application process. | Any KMS with a sign operation. A file on disk works and is a downgrade; the deployment guide says so plainly rather than pretending otherwise. |
| Queue / workflow engineoptional | Durable retries and stage replay for long reviews. | Optional at low volume — the orchestrator has an in-process runner. Past a few hundred reviews a day you want the durable one. |
How the pieces fit
GitHub / GHES
│ webhook (HMAC-verified)
▼
┌─────────────────────────────────────────────┐
│ Orchestrator (your network) │
│ • admission control, pipeline, posting │
│ • holds the posting token — never leaves │
└───┬───────────────┬──────────────────┬──────┘
│ mints │ reads/writes │ prompts
│ 1h repo token │ │
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌──────────────┐
│ Sandbox │ │ Postgres │ │ Model provider│
│ per PR │ │ + vector│ │ (your keys) │
│ egress: │ └──────────┘ └──────────────┘
│ deny by │
│ default │ ┌──────────┐
└─────────┘ │ Object │ encrypted bundles, traces
│ storage │
└──────────┘The important line in that diagram is the one that is missing: nothing connects to us. A self-hosted deployment makes no callback to SuperDiffs infrastructure, and it does not need outbound access to our domain to function. Licence validation is an offline key.
The trade-offs
You get: code never leaves your boundary
Diffs go from your GitHub to your orchestrator to your model provider under your contract. There is no leg through our infrastructure, which is the entire reason the option exists.
You get: your own model contract
Rate limits, retention terms, region, and model choice are yours. If your legal team has already negotiated a zero-retention agreement, self-hosting is how you use it.
You give up: our benchmark numbers apply to our pinned models
Point the deployment at a different or older model and the quality characteristics change. The benchmark harness is public precisely so you can measure your own configuration instead of trusting ours.
You give up: same-day fixes
On the hosted service a prompt regression is fixed for you within hours. Self-hosted, you upgrade an image on your schedule, which is both the benefit and the cost.
You take on: isolation is now your problem
The sandbox executes analysers over untrusted code. If you weaken the isolation or the egress policy to make the deployment easier, you have taken on the risk that boundary was holding.
Data flow, self-hosted
| Data | Hosted by us | Self-hosted |
|---|---|---|
| Repository checkout | Our sandbox fleet | Your sandbox runtime |
| Diff content in prompts | Our account with the model provider | Your account, your contract |
| Findings and evidence | Our Postgres, in the EU | Your Postgres |
| Review metadata | Our Postgres | Your Postgres |
| Usage telemetry | Collected for billing and quality | Aggregate seat counts only, for licensing |
| Crash reports | Sent to our error tracker | Yours, or nowhere |
Upgrades and support
- Container images are published on a release channel with the same version numbers as the changelog, so you can read exactly what a bump changes — including whether it changes comment volume.
- Schema migrations run at start-up and are forward-only. Rolling back a release means rolling back to a version whose schema you still have.
- Prompt and model pins are part of the image. A self-hosted deployment does not silently change models underneath you.
- Support is a named channel with a response commitment in the agreement, not a shared inbox.
Getting started
Because the tier is not open yet, the honest next step is a conversation rather than a download. Write to sales@superdiffs.com with your GitHub flavour (cloud or Enterprise Server), your runtime (Kubernetes, Nomad, plain VMs) and your model provider, and we will tell you whether the deployment you need is one we can support today or one you would be waiting on.
If a security review is what you actually need, the trust centre and the security page answer most questionnaires without a call.