BNLGit
For people who already like Gitea

It is Gitea. Plus one thing.

BNLGit is built on the Gitea codebase. Every repository, issue, pull request, action, webhook and API call you use today works exactly as it does now. Upstream MIT notices are preserved verbatim. Change your remote, and your workflow is unchanged.

What is added is a BNLRepo: pair a repository and you get <repo>-llm beside it — a real Git repository holding a <path>.llm twin for every source file, so your agents read structured, line-anchored, verifiable context instead of guessing from file dumps.

Availability during the public beta

BNLGit is currently offered as a hosted service only — one shared instance, operated by us, with your own model keys. The self-hosted and dedicated-instance deployments described on this page are not part of the beta, and there is no public Lite source release yet.

The product capabilities below are real and are what you get on the hosted service; the deployment models are what changes. If a dedicated or on-premise instance is a requirement rather than a preference, mail hello@bnlgit.com — it changes how we prioritise. See pricing and security and data handling for what the shared beta does and does not isolate.

Nothing you rely on changes

The migration is one command.

BNLGit is not a fork that drifted. It tracks the Gitea codebase, and the additions sit alongside upstream behaviour rather than replacing it. If a thing worked on your Gitea, it works here.

the entire migration
# point the remote at BNLGit
git remote set-url origin git@app.bnlgit.com:your-org/your-repo.git

# ...that's it. Same protocol, same clients, same everything.
# Bringing issues and PRs across? Gitea's own migration tool is inherited unchanged.
Repos, branches, tags, LFS — identical Issues, PRs, reviews, projects — identical Actions & your workflow files — identical Webhooks, packages, teams — identical The Gitea REST API — identical

Pairing is opt-in, per repository. An unpaired repository on BNLGit is exactly a Gitea repository — no extra cost, no different behaviour, nothing generated.

The delta

Everything BNLGit adds, and nothing it doesn't.

Each row below corresponds to a capability the running instance reports at GET /api/v1/bnlgit/capabilities, which needs no authentication. You never have to take our word for what is switched on — ask the server.

Addition
What it means
BNLRepo pairs Included + Lite (soon)
A source repository gets a <repo>-llm mirror in which every source file has a <path>.llm twin, plus a repo-level _OVERVIEW.llm. It is a real Git repository — clone it, diff it, grep it, read it offline. Your context is never locked inside our product.
Typed, line-anchored facts Included + Lite (soon)
Each summary carries structured facts as well as prose: symbols, imports, API endpoints, database entities, side effects, security concerns and related files. Every claim and every fact carries source line spans, and those spans are re-validated against the pinned blob before anything is returned — so a fact can't quietly point outside the file it describes.
Sync cockpit & drift signal Included + Lite (soon)
Per-file state (pending, stale, current, unverified, failed), the verified-current percentage, a queued-cost estimate, and one green/yellow/red badge per repository. The thresholds behind that badge are returned by the capabilities endpoint rather than hidden — green at 90% verified-current, yellow at 70%, red on any failed summary or high-risk finding.
BYOK connections vault Included + Lite (soon)
Your provider keys — LiteLLM, OpenRouter, Fireworks, Anthropic, Azure OpenAI, or any OpenAI-compatible endpoint — encrypted at rest with AES-256 under a dedicated key held separately from the instance's general secret key. Models are chosen from the catalogue your connection actually returned, never a free-text guess. We never bill you for tokens.
Repo & fleet MCP servers Pro
Two read-only MCP servers — four repo-scoped tools and two fleet-scoped — so your agent queries the codebase and gets an evidence bundle back: the .llm excerpt plus the backing source span read at the recorded commit, with a jump-back URL so a human can check the answer in one click. Authenticated with an ordinary Gitea token; permissions are enforced per request against the same model the web UI uses.
Retrieval & reranking Pro
Lexical search over summaries and exact git grep over source, both always available, ranked by a trust ladder that down-ranks stale and unverified material and excludes it by default. Vector-ranked retrieval over summary chunks is available where a repository has been configured for it, and degrades to lexical — announcing that it has — where it has not. An optional cross-encoder reranking pass can be switched on per instance. The limits are documented in full.
Model bake-offs Pro
Compare two BYOK models on the same sample of your own files — latency, tokens, cost and a deterministic quality signal, side by side. Telemetry only: a bake-off never commits an alternate summary and never changes which model a repository is paired to. Rate-limited, cost-capped, and idempotency-key safe so a retry can't double-bill you.
Reversible repo steward Pro
Proposes grouped cleanup plans — summary drift, duplicate or orphaned files, security hotspots, dependency drift, AI churn — each finding carrying evidence, a risk rating and rollback steps. It proposes a branch and a pull request for you to review. It is prevented in code from targeting your default branch, and in fact performs no Git writes at all.
Managed worker & spend controls Pro
Background generation with per-organisation concurrency limits and three independent cost ceilings — per run, per organisation in flight, and per organisation over a rolling 24-hour window — each defaulting to a bounded value, so a misconfigured deployment is bounded rather than unlimited. Any request that would spend from your connection is refused unless it carries explicit cost consent, enforced server-side.
Fleet dashboards Pro
The same coverage, freshness and drift signals rolled up across every BNLRepo you can see, rather than one repository at a time — and a single fleet-wide search across all of them.

The four rows marked + Lite (soon) above are also the planned scope of BNLGit Lite, an AGPL-3.0-or-later, self-hosted edition. It has not shipped yet — see editions and capabilities for the exact plan, or mail docs@bnlgit.com to hear the day it does.

The part most vendors leave out

What BNLGit does not do.

You are a technical audience evaluating a tool that puts an LLM near your codebase. The limits are more useful to you than the pitch, so here they are without being asked.

  • Source code is always authoritative — a summary never is. The .llm mirror is a derived artefact. Every retrieval path hands back the backing source span alongside the summary specifically so a human or an agent can check it. If the two disagree, the code is right.
  • Stale summaries are labelled and down-ranked, never silently trusted. Freshness is tracked per blob SHA. A summary whose source has moved on is marked stale, pushed down the trust ladder, and excluded from results unless you explicitly ask for it. A summary imported without provenance is shown as unverified rather than backdated with an invented model and date.
  • Nothing is inferred about your provider, credential or model. Pairing requires you to name the connection and the model explicitly. There is no default, no fallback provider, and no free-text model box — only models the connection's own catalogue returned. If your key stops working, BNLGit stops generating rather than silently substituting something of ours.
  • The steward never deletes code on an LLM's say-so. It writes a proposal with evidence, risk and rollback steps. It cannot target your default branch, and it does not commit, push or open anything — a human does. There is no "apply" button that skips review.
  • Nothing generates itself by default. Pairing a repository spends nothing. A source change raises a flag; it does not queue work. Generation happens when a person asks for it and confirms an estimate first, and that confirmation is checked on the server, not just in the browser.
  • Semantic search is not on for every repository. Vector-ranked retrieval requires an embedding model configured on the pair and indexed chunks for the ref. Where that is not in place, queries fall back wholesale to lexical results and say so in the response. Within one repository it is vector or lexical, not a blended fusion of both. Cross-encoder reranking is off unless an operator turns it on. Read the search page before you rely on this.
  • We publish no benchmark numbers. We have not run a comparison we would be willing to defend in public, so we do not quote one. The argument on this page is mechanical — typed, current, line-anchored context is better input than a pile of raw files — and you should test it on your own repository during the trial rather than believe a chart.
  • The beta is hosted and shared. One instance, operated by us. Your repositories are isolated by the permission model, not by separate hardware. Instance-level settings are ours to set, not yours. There is no self-serve download and no public Lite source release in this beta, and there is no uptime SLA. The full security and data-handling page spells out what that does and does not mean.

Ask the server, not us. Every capability claim on this page is reported by the instance itself at GET /api/v1/bnlgit/capabilities, unauthenticated. If a page of ours ever disagrees with that endpoint, the endpoint is right and the page is a bug — mail docs@bnlgit.com and we will fix it.

14-day trial, then from $12 per month — billed by repository and storage, never per seat (prices in US dollars). A card is required at signup and is charged when the trial ends unless you cancel — full terms. The documentation is public and needs no account.