Run the loop on infrastructure you control.
Enterprise at Korvu isn’t a feature gate — the whole engine is open source. It’s a deployment shape: the review → fix → verify → propose loop running inside your network, against your Git, with your LLM keys, at organization scale.
Your code never has to leave your network.
Self-hosted Core is the whole system — engine, sandbox, run history — inside your boundary. By architecture, not by policy: diffs are read from your Git, fixes are verified on your runners, and the LLM is whichever endpoint you point it at.
sees run metadata, never diffs or source.
Capabilities, not claims.
Everything in this section exists and is self-hostable now. The next section is what doesn’t exist yet — labeled as such.
The full loop, no seat gate
Review, fix, verify, propose — the same engine at 5 engineers or 5,000. There is no enterprise tier between you and your own deployment, because the license forbids us from building one.
Receipts as audit artifacts
Every proposed fix carries its verification receipt: what ran, what passed, where it ran. Receipts attach to commits, so the evidence lives in your Git history — reviewable in the same place as the code.
Your models, your routing
Bring keys for the provider you already use, or point the engine at an OpenAI-compatible endpoint you host. Keys are read from your environment — on self-host, we never see them.
Not built yet. Said plainly.
These are commitments of direction, not shipped capabilities. We mark them honestly until they exist — the same rule the comparison table on the homepage follows.
SAML SSO & SCIM
Single sign-on and directory-driven provisioning for the Cloud control plane. Self-hosted Core sits behind whatever access control your infra already enforces.
◷ on the roadmapOrg-wide policy controls
One place to set verify-gate requirements, repo enrollment rules, and fix-proposal behavior across hundreds of repos — instead of per-repo config files.
◷ on the roadmapAudit-log export
Streaming engine and control-plane events to the log pipeline you already run, in a format your security tooling can ingest.
◷ on the roadmapManaged workers in your network
Cloud-managed, customer-hosted verification runners — the managed layer’s convenience with the self-host boundary. Follows Cloud GA.
◷ on the roadmapFrom first email to first verified fix.
No procurement theater. The engine is open source — most teams have it running before the first call.
Tell us your constraints
Air-gapped network, self-hosted models, multi-provider Git — start with the hard parts. An engineer reads the note and replies with specifics.
Working session on your infra
We walk the deployment together: where the engine runs, how the sandbox gets your toolchain, which repos go through the loop first.
Pilot on real PRs
A handful of repos, your reviewers in the loop, receipts on every proposed fix. Expand when the evidence says so — it’s your deployment either way.
Bring us your hardest constraints.
Self-hosted models, isolated networks, organization-scale rollouts. If the loop can run there, we’ll help you run it — and if it can’t yet, we’ll say so.
Cloud remains waitlist-only — enterprise conversations don’t skip the line, they shape it.