Self-Hosted AI Code Review: What It Actually Takes
"Self-hosted" is doing a lot of work in most vendor datasheets. It can mean a container that runs entirely inside your network, or it can mean a container that clones your repo locally and then ships the interesting parts to someone else's API. For a regulated team, the difference is the entire point.
This is a practitioner's guide to what self-hosting AI code review actually requires: why the perimeter matters, the failure modes that make a real gate necessary, the BYO-LLM landscape you'll choose from, and the specific things to demand from a vendor before you trust them with your source code. It leans on our 2026 market analysis; claims are dated as of July 2026. Gatekeep is the worked example, not the sales pitch.
Why Self-Hosting Matters
The pressure is structural, not fashionable. By 2026, 84% of developers have adopted or plan to adopt AI tools, 51% use them daily, and roughly 40% of all active code is AI-generated or AI-assisted. Velocity is up — developers report completing up to 126% more projects per week. So is the defect load: CodeRabbit's own analysis of 470 open-source PRs found AI-assisted changes average 10.83 issues per PR versus 6.45 for human-authored, with logic defects up 75% and security vulnerabilities occurring 1.5x–2x more often. Up to 48% of AI-generated code samples contain security weaknesses.
More AI code means more review load, which means teams reach for AI review. But if you operate inside a compliance perimeter, you can't just point a SaaS reviewer at your repos. Three constraints, from the market analysis, define the wall:
- Zero third-party data storage. Source code is critical proprietary IP. It cannot be cached, stored, or processed on external vendor servers.
- No multi-tenant outbound data flow. Authentication paths, database schemas, and cryptographic modules cannot be routed to public, multi-tenant cloud APIs.
- Absolute air-gap requirements. Defense, sovereign, and government networks require the platform to run inside an isolated network with zero outbound public internet access.
These come out of HIPAA, PCI-DSS, SOC 2 Type II, and the EU AI Act. Self-hosting is how you satisfy them: the review runs where the code already lives, and nothing crosses the perimeter.
The failure modes self-hosting alone doesn't fix
Deploying a reviewer inside your network solves where the code goes. It does not automatically solve whether the review means anything. Two failure modes from the analysis are worth naming, because they determine what your self-hosted tool must do:
- Auto-publish and alert fatigue. Most AI reviewers auto-publish every suggestion as a PR comment. Models generate style nitpicks and false positives; the PR timeline fills with noise; developers learn to ignore it. A review nobody reads is not a control.
- Trust without verification. Sonar's State of Code 2025 survey finds ~96% of developers don't fully trust AI-generated code, yet roughly half don't consistently verify it before committing. If the AI makes a wrong assumption or generates subtly broken code, the error merges straight into main. Advisory markdown comments do not stop this.
The conclusion: self-hosting gets your code off the wire, but a hard, system-enforced blocking gate is what turns AI review from advisory noise into an actual control. You need both.
The BYO-LLM Landscape
Self-hosting the review orchestrator is only half the architecture. The other half is the model — and where it runs decides whether your air-gap holds. Bring-Your-Own-LLM means you supply the inference endpoint instead of the vendor routing to a multi-tenant API. As of July 2026, three patterns dominate.
Open-weight models on your own hardware
Run open-weight coding models — Qwen2.5-Coder, Llama-3-70B, and similar — on your own GPUs, served through vLLM for high-throughput inference or Ollama for simpler single-node setups. This is the only pattern that supports a true air-gap: the model weights and the inference both live inside your network, with zero outbound calls. It costs you GPU capacity and some MLOps effort, and open-weight models may trail frontier models on the hardest reasoning, but nothing leaves.
Private cloud endpoints
If your compliance posture allows a dedicated, single-tenant cloud boundary, Azure OpenAI and Amazon Bedrock give you frontier-class models behind private endpoints inside your own cloud account, rather than a shared multi-tenant API. Your data stays within your cloud tenancy under your contractual controls. This is the middle ground — stronger models than most open-weight options, without the fully public multi-tenant exposure that a strict perimeter forbids.
What "BYO-LLM" must actually mean
Watch the scope carefully. As of July 23, 2026, CodeRabbit supports connecting your own model only on its self-hosted Enterprise tier, which requires 500 or more user seats via contact sales — on cloud plans the engine is managed. Real BYO-LLM means every inference call for the actual review goes to your endpoint, on any tier you can actually buy. Qodo (full BYOK), Bito, Sourcery, SonarQube, and Greptile's self-host tier support genuine BYO-LLM to varying degrees; verify it covers the review engine, not just a summary pass.
What to Demand From a Vendor
Deployment models are marketing until you check them against a specific list. Here is what a compliance-grade self-hosted reviewer must actually provide.
1. Zero telemetry, zero code storage
The container must operate with zero external telemetry and zero code storage. The only permitted outbound connection is to your LLM gateway. Ask directly: does the product phone home for analytics, licensing, or crash reporting? In an air-gapped deployment, any of those breaks the perimeter. "Self-hosted" with mandatory telemetry is not air-gap capable.
2. A blocking gate, not an advisory comment
The reviewer must register as a mandatory, blocking status check in your GitHub/GitLab branch protection rules. When a policy violation or a SAST/SCA finding lands, the merge button is programmatically locked — not commented on. This is the direct fix for auto-publish and approval bias. And crucially, the override path matters: a gate you can dismiss with a checkbox (as CodeRabbit's error-mode checks allow, as of July 2026) is not a compliance control. Demand a mandatory written-justification flow before any override is honored.
3. Audit evidence your auditor will accept
The gate must produce an immutable, exportable audit log capturing, at minimum, actor, target, date, and the written justification for every override. That is what turns a merge block into direct evidence for SOC 2 Type II, ISO 27001, and HIPAA. A hash-chained log is stronger still — tampering breaks the chain. Without this, you have a reviewer, not a governance layer, and your audit prep is still manual.
4. Dual-layer verification
Cost and false-positive control argue for a two-layer architecture. A deterministic layer does AST-based code-walking and dependency graphing to check imports, detect hardcoded secrets, and map architectural paths — cheap, exact, no LLM tokens. An agentic reasoning layer then passes that structured context to your private LLM to judge developer intent and business logic against your natural-language standards. The deterministic pass cuts token spend and noise; the agentic pass catches what rules can't express. This is the target architecture to grow into — and, as the Gatekeep example below shows honestly, the layer most early entrants (us included) ship after the core gate, not before it.
Vendor checklist
| Demand | Why it matters | Weak-form red flag |
|---|---|---|
| Zero telemetry / zero code storage | Preserves the air-gap perimeter | "Self-hosted" but phones home |
| BYO-LLM on the review engine | Nothing crosses to multi-tenant APIs | BYO-LLM only on a summary step |
| Blocking status check | Fixes auto-publish + approval bias | Advisory PR comments only |
| Forced-justification override | Bypass leaves a paper trail | Checkbox dismiss |
| Immutable, exportable audit log | Direct SOC 2 / ISO / HIPAA evidence | Logs exist but not exportable/immutable |
| Air-gap capable | Defense / sovereign / strict fintech | Requires outbound internet to review |
Source: 2026 market analysis, as of July 2026.
A Worked Example: Gatekeep
To make the checklist concrete, here is how one architecture answers each demand — including the row it does not fully satisfy yet. Gatekeep was built to the three pillars the market analysis lays out for a governance-first entrant, so it maps cleanly to the first five rows above; the sixth (dual-layer verification) is on the roadmap, and we say so plainly rather than imply a graph we don't ship.
- Deployment. A single container or Helm chart runs entirely inside your VPC or on-prem Kubernetes. Zero code storage, zero telemetry, and no outbound calls except to your LLM gateway — air-gap capable by design.
- BYO-LLM, mandatory on self-host. You route every review inference to your own endpoint: Amazon Bedrock, Azure OpenAI, or a local vLLM/Ollama instance running Qwen or Llama. On self-host there is no managed-model fallback that could leak code. (On the optional Cloud tier you may use BYO-LLM or our managed pool.)
- Blocking gate with forced justification. Gatekeep registers as a blocking status check in GitHub branch protection. A policy violation locks the merge button. Overriding requires a written justification, recorded in an immutable, hash-chained, exportable audit log — actor, target, date, reason.
- Review scope, stated honestly. Gatekeep reviews the diff plus bounded neighboring context in a single policy-aware pass to your private model, judging intent and business logic against your natural-language standards — no black-box score. It deliberately does not build a repository-wide dependency/semantic graph (a stated non-goal), and the deterministic AST pre-pass from row 4 above is on the roadmap, not shipped today. Broader PR-hotspot / neighboring-file context is the top post-MVP investment. Be skeptical of any vendor — us included — who claims a full codebase graph "today."
Honest scope, as of July 2026: Gatekeep is GitHub-only today, and it is a governance-first reviewer — not a monorepo-indexing engine like Greptile or a stacked-PR tool like Graphite. The point of the worked example is the pattern, not the pitch: if a vendor can't answer the six checklist rows above — or can't tell you honestly which ones are shipped versus roadmap — self-hosting won't buy you the compliance posture you think it does.
Newer and broader: if you are still deciding whether self-hosting is even possible for your stack, start with can you run AI code review without sending your code to the cloud? It covers the three architectures vendors all call "self-hosted" and which one actually survives an air gap. This post assumes you have made that call and want the implementation detail.
FAQ
Does self-hosting AI code review mean my code never leaves the network?
Only if the model runs inside the perimeter too. Self-hosting the orchestrator but routing review inference to an external API still crosses the boundary. True containment requires BYO-LLM to an in-network endpoint (open-weight models via vLLM/Ollama) or, at minimum, a private single-tenant endpoint like Azure OpenAI or Bedrock.
Which open-weight models are used for self-hosted code review?
As of July 2026, the common choices are open-weight coding models such as Qwen2.5-Coder and Llama-3-70B, served via vLLM for throughput or Ollama for simpler deployments. They run entirely on your own hardware, which is what makes a true air-gap possible.
Why isn't an advisory AI reviewer good enough for compliance?
Two reasons from the data: auto-published comments create alert fatigue that developers learn to ignore, and roughly half of developers don't consistently verify AI-generated code before committing even though ~96% say they don't fully trust it (Sonar, State of Code 2025). Advisory markdown does not stop a bad change from merging. A blocking status check does.
What makes an audit log "compliance-grade"?
It must be immutable and exportable, and capture actor, target, date, and a written justification for every override. A hash-chained log adds tamper-evidence. That combination is what serves as direct evidence for SOC 2 Type II, ISO 27001, and HIPAA — a plain event log does not.
Is a private Azure OpenAI or Bedrock endpoint enough for an air-gap?
For a strict air-gap (defense, sovereign) that forbids all outbound internet, no — you need in-network open-weight models. For teams whose policy permits a dedicated single-tenant cloud boundary, private Azure OpenAI or Bedrock endpoints keep data within your own tenancy and satisfy no-multi-tenant-outbound requirements.