TL;DR: Serge is Hugging Face’s Apache-2.0, GitHub-native AI code reviewer. It reads pull request diffs, posts inline review comments, and talks to any OpenAI-compatible endpoint — so you can point it at your own vLLM or Ollama server instead of a paid SaaS. The catch: GitHub’s cloud runners can’t reach a model on your laptop, so a truly local setup needs the GitHub App mode or a self-hosted runner.

	GitHub Action	GitHub App (webhook)	Web app (staged)
Best for	One repo, fastest start	Orgs, fork-heavy projects, fully local models	Human-in-the-loop review
Setup effort	~10 min (add secret + workflow)	Host a service + register an App	Deploy the app yourself
Reaches your LAN model?	Only via self-hosted runner	Yes — runs on your server	Yes
Fork PRs handled safely?	Limited (secret access)	Yes (App installation token)	Yes

Honest take: For a single project on a public model endpoint, start with the GitHub Action — it’s live in ten minutes. If you want reviews driven by a model that never leaves your network, skip straight to the GitHub App mode on a box that can see your vLLM server.

What Serge actually is

Serge is an open-source code review bot that Hugging Face released in mid-June 2026 (announced June 12). It plugs directly into GitHub pull requests: it reads the diff, reasons about it with a large language model, and writes review comments the way a human reviewer would — flagging correctness bugs, security issues, behavior changes, and missing tests.

The important part for this site: Serge is Apache-2.0 licensed, the source lives at github.com/huggingface/serge, and it does not hard-wire you to a hosted model. It “talks to OpenAI-compatible chat completion endpoints” and works with OpenAI, the Hugging Face Router, and — the reason it belongs on aifoss — local vLLM, TGI, and LM Studio endpoints, plus any custom OpenAI-compatible provider. Ollama exposes exactly that kind of endpoint at http://localhost:11434/v1, so it fits the same slot.

That combination — Apache-2.0 code plus bring-your-own-model — is what separates Serge from the commercial reviewers (CodeRabbit, Greptile, Qodo) that dominate this space. Those tools are good, but they bill per seat and send your diffs to their cloud. Serge lets you keep both the reviewer and the model on infrastructure you control.

Hugging Face is not dogfooding a demo, either: Serge is already used in the review workflow for its own high-traffic repositories, including diffusers and transformers, as well as on the Serge repo itself.

Why self-hosters should care

If you have already stood up a local inference server for chat or coding — the kind of Ollama + Open WebUI stack or vLLM deployment covered elsewhere on this site — Serge is close to free capability on top of hardware you already own. The marginal cost of an automated reviewer becomes electricity, not a monthly invoice that scales with headcount.

There is a second reason that matters more for some teams than money: data sovereignty. Sending proprietary source diffs to a third-party reviewer is a real problem for regulated industries, contractors under NDA, and anyone building something they’d rather not train someone else’s model on. A reviewer whose model runs on your own GPU sidesteps that entirely.

The honest counterpoint, which this guide will keep coming back to: local models are not GPT-5.5. A 7B–14B model will catch obvious bugs, missing null checks, and forgotten tests, but it will miss subtle logic errors a frontier model catches. Budget your expectations to the model you can actually run.

The three deployment modes

Serge ships in three shapes, and picking the right one up front saves an afternoon.

1. GitHub Action — the fastest path. You add your model’s API key as a repository secret, drop a workflow file in, and trigger a review by commenting on a PR. The limitation is structural: GitHub’s hosted runners live in GitHub’s cloud, so they can reach api.openai.com or the Hugging Face Router but cannot reach a model bound to localhost on your workstation. To use a local model with the Action, you need a self-hosted GitHub Actions runner on a machine that can see your inference server.

2. GitHub App (webhook) — the mode built for organizations and fork-heavy projects. The App runs as a hosted service you operate; it receives GitHub comment events over a webhook and publishes reviews using a GitHub App installation token. Because it runs on your own server, it can talk to your vLLM or Ollama endpoint directly — no runner gymnastics. It also solves a genuine security headache: forked pull requests often can’t access repository secrets, so an Action-based reviewer breaks on exactly the external contributions you most want reviewed. The App’s installation token sidesteps that.

3. Web app (staged) — a human-in-the-loop deployment where reviews are staged for a person to approve before they post. Useful if you want AI assistance but not AI comments landing unsupervised on contributor PRs.

Quick start: the GitHub Action

For a single repository pointed at a reachable endpoint, this is the ten-minute version.

First, add your model endpoint’s key as a repository secret. In your repo: Settings → Secrets and variables → Actions → New repository secret, named LLM_API_KEY. If you’re using a local endpoint that ignores auth (Ollama does), any non-empty string works — set it to ollama or similar so the client sends something.

Then install the Serge workflow. The configuration Serge needs is deliberately small: an API base, an API key, and optionally a model. If you don’t specify a model, Serge queries the endpoint’s /models route and uses the first one returned. A workflow triggered on pull request comments looks roughly like this — check the Serge docs for the exact action reference and input names, which are versioned:

name: Serge Review
on:
  issue_comment:
    types: [created]
jobs:
  review:
    if: github.event.issue.pull_request
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Serge
        uses: huggingface/serge-action@v1   # confirm ref in the docs
        with:
          api_base: https://router.huggingface.co/v1
          model: Qwen/Qwen3-Coder-30B-A3B-Instruct
        env:
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}

With the workflow in place, trigger a review by commenting on any pull request:

@askserge please review

Serge picks up the comment event, pulls the diff, sends it to your configured model, and posts its findings back on the PR.

Wiring Serge to a local model

Here is where the “self-hosted” promise gets real — and where the biggest gotcha lives.

The mechanics are trivial: Serge only needs an OpenAI-compatible base URL. Point api_base at your server and you’re done.

• vLLM (recommended for review workloads — it batches well and serves concurrent PRs): start it with an OpenAI-compatible server, then set api_base: http://YOUR_HOST:8000/v1. See the vLLM setup guide for the serving command and auth.
• Ollama: it exposes an OpenAI-compatible endpoint automatically at http://YOUR_HOST:11434/v1. Pull a coding model (ollama pull qwen3-coder-next), then set api_base to that URL.
• TGI / LM Studio: both expose OpenAI-compatible routes and slot in the same way.

The gotcha: the machine running Serge must be able to reach that URL. If you use the plain GitHub Action, the runner is in GitHub’s cloud and localhost means the runner, not your desk. Your options, in order of practicality:

1. GitHub App mode on a server that can see your inference host. This is the intended architecture for local models. Run the Serge App and vLLM on the same LAN (or the same box), and reviews never leave your network.
2. A self-hosted GitHub Actions runner on a machine with line-of-sight to your model server. Keeps the Action workflow but moves execution onto your hardware.
3. A tunnel (Tailscale, a reverse proxy with auth) exposing your endpoint to a cloud runner. Workable, but you’re now punching your model server out to the internet — lock it down, because exposed inference endpoints are a real attack surface.

If you don’t own a GPU big enough to run a review-grade model but still want everything off the SaaS reviewers, renting a GPU by the hour is the middle path: spin up a RunPod instance, serve the model with vLLM, and point the Serge App at it. You control the model and the data path without buying an RTX 5090. For the buy-vs-rent math on review models specifically, runaihome.com’s local AI hardware guides break down the VRAM tiers.

The review policy file: .ai/review-rules.md

Out of the box Serge gives generic feedback. To make it review your code the way you want, you add a rules file.

Serge reads the repository’s review policy from .ai/review-rules.md on the default branch. It’s plain Markdown — you write, in prose, what the reviewer should focus on and what it should ignore. A practical starting point:

# Review rules

Focus on:
- Correctness and logic errors
- Security issues (injection, auth, secrets in code)
- Behavior changes that aren't covered by tests
- Missing or inadequate test coverage

Ignore:
- Pure style/formatting (the linter handles this)
- Generated files under dist/ and *.lock
- Subjective naming preferences

Two design choices here are worth understanding, because they’re deliberate:

First, telling the reviewer what to ignore is as valuable as telling it what to catch. Local models love to pad reviews with style nitpicks that your formatter already enforces. An explicit ignore-list keeps the signal-to-noise ratio usable.

Second — and this is a genuine security feature — Serge loads the rules from the default branch, not from the PR branch. That means a pull request can’t modify .ai/review-rules.md to weaken the policy used to review itself. A malicious contributor can’t open a PR that says “ignore all security checks” and have it apply to that same PR. The policy is fixed by whoever controls main.

Security model, briefly

The reason the GitHub App mode exists at all is a security one. When a fork opens a pull request, GitHub deliberately withholds repository secrets from Actions triggered by that fork — otherwise any stranger could exfiltrate your keys with a malicious workflow change. That protection also breaks secret-dependent reviewers on fork PRs.

The App gets around it correctly: it authenticates with a GitHub App installation token scoped to the review action, rather than needing your LLM_API_KEY to be readable by fork-triggered runs. If you maintain an open-source project that takes external contributions, this alone is the argument for App mode over the Action.

Whichever mode you choose, the same hardening rules apply to the model endpoint it calls. Don’t bind vLLM or Ollama to 0.0.0.0 on an untrusted network, put auth in front of it, and firewall the port. The Ollama exposed-instances post-mortem on this site covers why that matters.

When NOT to use Serge

Serge is a good fit for a lot of teams, but not all:

• You have no local inference and don’t want to run any. If you’re going to call OpenAI’s API anyway, a hosted reviewer like CodeRabbit is less to operate. Serge’s advantage evaporates when the model isn’t yours.
• You need frontier-level review quality and can’t run a frontier model. A 7B–14B local model produces useful but shallow reviews. If your codebase has the kind of subtle concurrency or type bugs that need a top-tier model, and you can’t self-host one, a SaaS reviewer running GPT-5.5-class models will simply catch more.
• You want zero infrastructure. The GitHub App and web-app modes are services you operate. That’s a maintenance commitment. The plain Action is lighter, but then you’re back to a cloud-reachable model.
• Your org forbids bots commenting on PRs unsupervised. Use the staged web-app mode, or don’t automate the posting step at all.

Serge vs the alternatives

	Serge (self-hosted)	CodeRabbit / Greptile	Ollama Action bots
License	Apache-2.0	Proprietary SaaS	Mostly MIT/Apache
Model	Any OpenAI-compatible (local or cloud)	Vendor-hosted frontier	Local Ollama only
Data path	Stays on your infra (App mode)	Leaves to vendor	Stays local
Cost	Compute only	Per-seat/month	Compute only
Fork PR handling	Yes (App token)	Yes	Often broken
Review depth	Bounded by your model	Frontier-grade	Bounded by your model

The generic “code review using Ollama” GitHub Actions that predate Serge do the local-model part, but they tend to be single-purpose scripts without the fork-safe token handling, the default-branch policy file, or the multi-mode deployment story. Serge is the more complete piece of infrastructure, and it’s backed by Hugging Face’s own production use.

If you’re evaluating the coding-assistant side rather than the review side, aicoderscope.com covers the self-hosted coding tools that pair naturally with a Serge review gate — write with a local agent, review with a local reviewer, ship without a single API call leaving your network.

FAQ

Is Serge really free? The Serge software is Apache-2.0, so yes — free to use, modify, and self-host commercially. Your only cost is the compute to run the model it calls (and any GitHub App hosting you choose).

Can I run it fully offline / air-gapped? The model half, yes — point Serge at a local vLLM or Ollama endpoint and no inference data leaves your network. But Serge reviews GitHub pull requests, so it needs to reach GitHub itself. For a fully air-gapped setup you’d need a self-hosted GitHub Enterprise instance.

Does it work with Ollama specifically? Ollama exposes an OpenAI-compatible endpoint at http://localhost:11434/v1, which is exactly what Serge expects, so it works as a custom OpenAI-compatible provider. Hugging Face’s own docs call out vLLM, TGI, and LM Studio by name; Ollama fits the same interface. For a busy repo, vLLM handles concurrent reviews better.

Which model should I use for reviews? A coding-tuned model in the 14B–32B range is the sweet spot for local review — big enough to reason about diffs, small enough to serve on one 24GB GPU. Qwen3-Coder variants and Devstral are reasonable starting points. Reserve frontier models for the reviews that actually need them.

How is this different from the commercial reviewers? Same core idea — LLM reads your diff, posts comments — but Serge is open source and lets you supply your own model, so your code and the reviewing model both stay on infrastructure you control. The tradeoff is that you operate it, and review quality is capped by the model you can run.

Can a contributor disable the review by editing the rules? No. Serge loads .ai/review-rules.md from the default branch, not from the PR branch, so a pull request can’t weaken the policy used to review itself.

Sources

• Introducing Serge: GitHub-Native AI Code Review — Hugging Face Blog
• huggingface/serge — GitHub repository (Apache-2.0)
• Automating Code Review with GitHub Actions — Hugging Face docs
• Ollama OpenAI compatibility — Ollama Blog
• Hosting your own GitHub Actions runners — GitHub Docs
• Self-Hosted AI Code Review security considerations — RedFox Security