Coming from Gitea

If you already run or use Gitea, this page is the whole migration story.

What does not change

BNLGit is built on the Gitea codebase. It is not a fork that diverged years ago and drifted; it is Gitea plus a set of additions, with upstream's MIT notices preserved verbatim.

That means everything you already know still applies:

• Repositories, branches, tags, LFS — identical.
• Issues, pull requests, reviews, milestones, projects, labels — identical.
• Actions, runners, and your existing workflow files — identical.
• Webhooks, packages, organizations, teams, permissions — identical.
• The Gitea REST API and its tokens — identical. Existing scripts work.
• git itself — obviously identical. Same protocol, same clients, same everything.

For any of the above, Gitea's documentation ↗ is the correct reference and we do not attempt to duplicate it.

What you actually have to do

Move the remote:

git remote set-url origin git@app.bnlgit.com:your-org/your-repo.git

That is the migration. If you would rather pull the whole repository across including issues and pull requests, use Gitea's built-in migration tool (New → Migration), which BNLGit inherits unchanged.

What is added

One thing, from which everything else follows: you can pair a repository. Pairing creates <repo>-llm beside it, holding a <path>.llm twin for every source file. See The BNLRepo mirror model.

Pairing is opt-in per repository. An unpaired repository on BNLGit is exactly a Gitea repository, costs nothing extra, and behaves in no way differently.

Things that surprise people

The mirror is a real repository, not a database view. You can clone your-repo-llm, read it offline, diff two commits of it to see how your codebase's shape changed, and grep it with ordinary tools. This is deliberate: your context should not be locked inside our product. If you cancel, you keep the mirror the same way you keep any other repo.

Nothing generates itself by default. Pairing a repository does not start spending. A source change raises a needs_regeneration flag, but by default nothing is claimed for work until a human presses Generate — which sets a separate regeneration_requested flag. Auto-regeneration is off per BNLRepo. This is a spend-safety decision, not an oversight.

Old summaries are labelled, not backdated. If a summary is imported from before BNLGit, or lacks provenance, it is shown as unverified rather than given an invented model and date. It stays that way until it is genuinely regenerated.

Registration is closed on the hosted service. There is no public sign-up form on the forge. Accounts are minted by the trial checkout flow only.

Self-hosting

BNLGit's Pro edition supports a downloadable, single-customer deployment, and the running edition of any instance reports whether that is available via its capabilities endpoint.

During this public beta we are offering the hosted service only. There is no self-serve download and no public Lite source release yet. If a dedicated deployment is a hard requirement for you rather than a preference, mail hello@bnlgit.com and say so — it changes how we prioritise.

Licensing

BNLGit is an independent product and is not affiliated with or endorsed by Gitea Ltd.

Upstream Gitea and Gogs code remains under the MIT licence, with the original notices shipped intact. BNLGit Lite modifications are AGPL-3.0-or-later. The Pro bundle is distributed under a separate proprietary EULA together with its third-party notices. See Editions and capabilities.