Self-Hosted AI Code Review with Ollama

Most AI code review tools send your diff to a cloud provider. That’s fine for many teams, but if your organization has data-residency rules, operates in an air-gapped environment, or simply has a strong preference for keeping source code off third-party servers, the standard BYOK path through a gateway like OpenRouter still isn’t enough. The diff still reaches an external provider. This post covers the one configuration that closes that gap: pointing Robin, a free MIT-licensed GitHub Action, at your own Ollama server. With a private Ollama endpoint, the diff travels from GitHub Actions to infrastructure you control and nowhere else.

Key Takeaways

• Gateway services like OpenRouter forward your diff to a third-party model provider. A private Ollama endpoint keeps it in your own infrastructure.
• Robin supports any OpenAI-compatible endpoint, including Ollama, via three GitHub Actions secrets.
• A self-hosted runner or network route is required so your Actions job can reach a private Ollama instance.
• Local models have real tradeoffs: hardware requirements, slower inference, and weaker multi-file reasoning than frontier models.
• The setup is reversible. Switching back to a hosted model is a single secret change.

Why Self-Host an AI Code Reviewer?

The core reason is control over where your code travels. When you send a diff to a SaaS code review tool or even a BYOK gateway, the data leaves your network. Gateways like OpenRouter are transparent about this: they forward your request to the underlying model provider’s API. That provider’s data-handling policy then applies to your code.

The instinct to keep code in-house is widespread, not fringe. In Cisco’s 2024 Data Privacy Benchmark Study — a survey of 2,600 security and privacy professionals across 12 countries — 27% of organizations said they had banned generative-AI tools outright over privacy and data-security risks, even as 48% admitted staff were entering non-public company information into them. Self-hosting is how teams resolve that tension for code review specifically: keep the capability while removing the external model provider from the path. (As the setup section below covers, full network isolation also means running the CI job on your own runner — not just the model — since a cloud runner still checks out your code on someone else’s infrastructure.)

For teams under compliance regimes that restrict source code to specific jurisdictions or to internal systems, that forwarding is a non-starter regardless of what the gateway’s privacy policy says. For teams in air-gapped environments, it’s simply not possible.

A self-hosted Ollama instance runs entirely on hardware you own or rent inside a network perimeter you control. Nothing leaves that perimeter. That’s the strict-control path.

Beyond compliance, some teams self-host for cost predictability. Running a model locally means inference costs are bounded by electricity and hardware amortization, not per-token metering. At low-to-medium PR volumes, this can work out cheaper than hosted inference.

How the Architecture Works

The setup has three components: GitHub Actions (where Robin runs), your Ollama server, and the model you pull onto it.

When a pull request opens, Robin’s GitHub Actions workflow picks up the diff and sends it to the URL in LLM_BASE_URL. Ollama exposes an OpenAI-compatible API at http://your-server:11434/v1, so Robin can talk to it directly with no adapter layer needed.

The catch is network routing. GitHub’s default hosted runners run on GitHub’s infrastructure. If your Ollama server is on a private network with no public exposure, a default GitHub-hosted runner can’t reach it. You have two options:

• Self-hosted GitHub Actions runner — run a runner inside your own network, on the same LAN or VPN as the Ollama server. This is the cleanest solution for genuinely air-gapped setups.
• Public or VPN-accessible Ollama — expose Ollama to the internet (ideally behind an auth proxy or a Cloudflare Tunnel), or route GitHub-hosted runners through a VPN. This is simpler to set up but involves more exposure than a fully internal deployment.

Which option fits depends on your threat model. For strict air-gap compliance, a self-hosted runner is the right call. For “we just don’t want to trust third-party inference APIs,” a Cloudflare Tunnel or similar is usually sufficient.

Setting Up Ollama

If you don’t have Ollama running yet, installation is a single command on Linux or macOS. Visit ollama.com for the current install instructions, then pull a model suited to code review. Code-specialized models like codellama, deepseek-coder, or qwen2.5-coder tend to perform better on diff analysis than general-purpose models of the same size.

# Example: pull a code-focused model
ollama pull qwen2.5-coder:7b

Ollama starts an HTTP server by default on port 11434. The OpenAI-compatible endpoint is at /v1, so the full base URL you’ll use is:

http://your-ollama-host:11434/v1

If Ollama is on the same machine as a self-hosted runner, use http://localhost:11434/v1. If it’s on a separate server, use that server’s IP or hostname.

By default, Ollama only binds to localhost. To accept connections from other hosts, set the environment variable OLLAMA_HOST=0.0.0.0 before starting Ollama (or set it in the systemd unit if you’re running Ollama as a service). Be thoughtful about what network this exposes Ollama on.

Installing Robin and Configuring the Secrets

Install Robin from the root of your repository:

npx robin-review

No npm? Install with curl instead:

curl -fsSL https://robinreview.dev/install.sh | bash

Both commands configure the Git repository you are currently in. The workflow and secrets are per repository; the companion agent skill is installed globally once per machine.

This creates the GitHub Actions workflow file. Commit and push it to your repo.

Then add three repository secrets in GitHub (Settings, then Secrets and variables, then Actions):

The LLM_API_KEY note is worth emphasizing: Ollama’s default configuration accepts requests without authentication. Robin still requires the secret to be present. Set it to any non-empty value and it will work. If you’ve added authentication to your Ollama proxy (recommended for any public-facing deployment), use the real token.

Once those secrets are in place, open a pull request. Robin will post a review comment automatically. Two slash commands work in any PR comment without additional configuration:

• /robin — re-runs the review, useful after pushing new commits
• /summary — posts a short plain-language overview of the PR changes

What to Expect from Local Models

This is the part that deserves honesty. Local models are not the same as frontier models, and the gap is real.

On the positive side, models like qwen2.5-coder and deepseek-coder are genuinely good at catching common issues: obvious bugs, missing error handling, style inconsistencies, and potential null-pointer situations. For a team that currently has no automated review step, even a mid-sized local model adds clear value.

The limitations show up in a few specific areas. Multi-file reasoning is weaker. If a change in one file has a subtle implication for a type defined three files away, a 7B or 13B model is likely to miss it where GPT-4o or Claude would not. Review comments also tend to be shorter and less explanatory. And inference on CPU hardware is slow enough that a review of a medium-sized diff can take a minute or more.

Hardware is the other honest constraint. Running a 7B model requires at least 8GB of VRAM (or a lot of RAM if running on CPU, with the associated slowness). A 13B or 34B model needs correspondingly more. If your team doesn’t already have a GPU server available, buying or renting one changes the cost calculus compared to just paying per-token to a hosted provider.

The Tradeoffs: When Self-Hosting Is Worth It

Self-hosting is clearly worth it when:

• Your security policy prohibits source code from leaving your network boundary, full stop.
• You operate in an environment with no reliable internet connectivity.
• You already have GPU hardware running and want to put it to use.
• You need to audit every step of the review pipeline and can’t accept a third party in the chain.

It’s probably not worth it when:

• Your real concern is cost, and you don’t have existing GPU hardware. Paying for inference from a hosted provider is almost certainly cheaper than buying and maintaining a GPU server for PR review alone.
• You want the best possible review quality. Frontier models are meaningfully better at complex reasoning, and the gap matters for security-sensitive or architecturally complex code.
• Your team is small and review volume is low. The operational overhead of running your own model server doesn’t pay off at low volume.

The middle path for teams that want less data exposure without full self-hosting is a direct API connection to a major provider (OpenAI, Anthropic) rather than a gateway. Your diff still leaves your network, but it goes directly to one provider under a well-established data processing agreement, not through a third-party aggregator.

Switching Back Is One Secret Change

One thing worth knowing before you start: this setup is fully reversible. If you self-host Ollama and find the model quality doesn’t meet your needs, switching Robin back to a hosted model is updating two secrets in GitHub. No workflow changes, no reinstallation. The architecture Robin uses means the LLM backend is entirely swappable at any time.

That reversibility makes it reasonable to try the self-hosted path even if you’re not certain it’s the right long-term choice. Run it for a sprint, evaluate the review quality against your actual PRs, and decide from real experience rather than benchmarks.

In our experience maintaining Robin, that’s exactly how the self-hosted setups that stick get chosen: a team points LLM_BASE_URL at an internal Ollama box for two weeks, reads the actual review comments on their own PRs, and keeps it only if the quality clears their bar. The swappable backend is what makes that trial low-risk — nobody has to commit to GPU ops before seeing whether local review is good enough for their codebase.

FAQ

Can Robin reach an Ollama server on localhost from a GitHub-hosted runner?

No. GitHub-hosted runners run on GitHub’s infrastructure, so localhost refers to the runner machine, not your machine. You need either a self-hosted runner on the same network as Ollama, or a publicly accessible Ollama endpoint (behind a proxy or tunnel).

Does Ollama need an API key?

Ollama’s default configuration doesn’t require authentication. Robin requires LLM_API_KEY to be set, so use any placeholder string. If you’ve added an authentication layer in front of Ollama (recommended for any internet-facing setup), use that token.

Which Ollama model should I start with?

Code-specialized models outperform general models on PR review tasks. Good starting points are qwen2.5-coder:7b (for 8GB VRAM) or deepseek-coder-v2:16b (for 16GB+ VRAM). Larger models produce better reviews but require more memory and are slower.

Will the review quality match a hosted frontier model?

Not quite. Local models are useful and catch real issues, but they’re weaker at multi-file reasoning and long-context analysis than GPT-4o or Claude Sonnet as of this writing. The gap is the honest tradeoff for keeping your code fully on-premises.

Can I use Robin with GitLab or Bitbucket instead of GitHub?

Robin is a GitHub Action and works with GitHub’s pull request workflow only. See the Robin docs for current platform support status.

Where to Go From Here

The Robin documentation has the complete setup reference, including custom prompt configuration and troubleshooting for common network and permissions issues. If you’re still evaluating whether Robin fits your workflow, the tools overview covers how it compares to other approaches.

If you landed here and the self-hosted path is more complexity than you need right now, the same three-secret setup works with any hosted OpenAI-compatible provider. The configuration is identical; only the LLM_BASE_URL and LLM_MODEL values change.