# Your diff should never leave your machine: the Ollama path for air-gapped repos. > How CommitBrief runs LLM code review with zero network egress. For SOC2-restricted repos, defense work, fintech and healthcare codebases — and an honest look at the quality trade-off. Published August 4, 2026 by CommitBrief (https://commitbrief.com) Canonical URL: https://commitbrief.com/blog/air-gapped-with-ollama/ Tags: privacy, ollama, air-gapped, security --- There is a widely held assumption that using AI on your code means handing your code to a vendor. This assumption is false, but it's been allowed to persist because most popular LLM tooling does in fact phone home. The Ollama path through CommitBrief is the counter-example. This post is a careful tour of how it works, who it's for, and an honest look at the quality trade-off it implies. ## What "air-gapped" actually means here The Ollama provider talks to `http://localhost:11434` — your machine, on a loopback interface. CommitBrief makes no other outbound network calls when this provider is selected. No telemetry endpoint, no auto-update check, no analytics ping, no SaaS account verification. Your diff, your `COMMITBRIEF.md`, and the model's response never cross your machine's boundary. This is verifiable. The Ollama provider's HTTP client targets exactly two paths: - `POST /api/chat` — the actual review call - `GET /api/tags` — model discovery, used by the setup wizard No other URLs are touched. You can confirm this by setting `HTTP_PROXY=http://invalid.local` in your environment and watching every other provider fail while Ollama keeps working. The CLI binary doesn't try to reach the internet for any reason. ## Who needs this The classic answer is "regulated industries." That's right but incomplete. The full list, from what I've heard from users: - Defense contractors with strict ITAR-bound code - Fintech teams with PCI-DSS scope on their repos - Healthcare engineers with HIPAA-touching codebases - Government and public-sector teams with sovereign-data requirements - Companies in jurisdictions that legally restrict cross-border data transfer - Open-source maintainers working on cryptographic libraries who don't want third-party model providers seeing their unreleased work - Anyone who simply doesn't want to be in the business of trusting another vendor with their unreleased code The first five categories often _legally cannot_ use a cloud LLM provider on their codebase. The last two often _choose not to_, which is equally valid. ## The setup Assume Ollama is installed and a coder model is pulled: ```sh ollama pull qwen2.5-coder:14b ``` Then point CommitBrief at it: ```sh commitbrief setup --local # In the wizard: pick ollama, pick qwen2.5-coder:14b ``` The `--local` flag saves the configuration under `./.commitbrief/config.yml` and auto-adds `.commitbrief/` to your `.gitignore`. From this point, every `commitbrief --staged` in this repo goes to your local Ollama instance. The same `commitbrief setup` (without `--local`) would write a user-global config under `~/.commitbrief/config.yml` — useful when you want all your repos to default to Ollama. A `TestConnection` step in the wizard hits `/api/tags` rather than spending inference time on a real completion. If Ollama isn't running or the model isn't pulled, you find out immediately rather than after the first review attempt. ## The quality trade-off, honestly I'm not going to tell you a local 14B model is the same as Claude Sonnet 4.6. It isn't. Sonnet has more parameters, more training, more capability at picking up subtle context. A serious comparison across the same diff usually shows the commercial model catching one or two findings the local model misses, especially on architecture-level concerns. But the gap that matters isn't the gap between local and commercial. It's the gap between local and _no review_. If your compliance posture means you can't use a cloud provider, you're not choosing between qwen and Sonnet — you're choosing between qwen and nothing. In that frame, qwen wins decisively. A few honest observations from running both side by side over several months: - For mechanical findings (pattern violations, consistency drift, typical bug shapes), a good local coder model is competitive with cloud models. The hard part of these findings is consistency, not capability, and consistency is a model-architecture question more than a parameter-count question. - For "this function answers the wrong question" findings, neither local nor cloud LLMs are reliable — those still belong to humans. So choosing local doesn't lose you anything there. - For nuanced architecture concerns ("this looks fine but the cross-service implications are wrong"), the cloud model is genuinely better. If your work is heavy on this kind of finding, the local path will feel thinner. Pick a model that's actually trained on code. The generic chat-tuned models will work but produce noisier output than a coder-tuned model of the same size. `qwen2.5-coder`, `deepseek-coder`, and `codellama` families are all worth trying. ## What you gain beyond privacy Two side benefits the Ollama path produces almost by accident: - **No per-token cost.** A review on Ollama is paid for in electricity. The local response cache makes re-runs free anyway, but with Ollama even the first run is cost-free at the dollar level. - **No rate limits.** You're not going to hit a 429 from your own machine. For teams that run review in CI on every PR, that's the difference between "this works reliably" and "this fails 3% of the time on a busy day." These aren't reasons to switch _to_ Ollama if you don't need air-gapping. The commercial models will outperform a 14B local model on quality. But for teams who'd already chosen the local path for compliance reasons, these are quiet wins. ## When to keep the cloud option For everyone outside the regulated cases, my honest recommendation is to keep at least one cloud provider configured. CommitBrief lets you switch per-run with `--provider`, so nothing forces you to commit to one path. Run Ollama by default; reach for Anthropic or OpenAI on the rare diff where you want a second opinion from a more capable model. If you arrived here from [the CLI-vs-App post](/blog/cli-vs-github-app), this provider flexibility is a direct consequence of the CLI architecture — a GitHub App can't realistically offer "switch to a local model for this one run." And if you arrived from the [solo developer post](/blog/solo-developer-second-pair-of-eyes), the Ollama path is what makes review economically viable for an indie's lowest-priority side project. The next post turns to a configuration detail that has more impact than it sounds: the three-layer filtering pipeline, and how to keep noisy paths out of your review without losing the signal you care about.