Self-hosted git forge
The mirror already speaks git, for repositories it caches from somebody else. The forge is the other half of that: repositories whose canonical home IS your machine — your own code, hosted beside the dependencies it builds against, in one URL space and behind one set of credentials.
Management and browse
Create, list, update, and delete repos over REST, and browse branches, commits, trees, blobs, and READMEs — all of it shelling out to git plumbing, with names, refs, and paths strictly validated, and every mutation audited.
Clone is anonymous; push is token-gated, over git http-backend. A push is handed to a detached worker so the accept loop never stalls behind a large receive-pack.
Push triggers the build
This is the part that makes the forge worth having rather than just convenient: git push can be the whole deploy. Creating a repo installs a post-receive hook, inert until the coordinator's URL and a shared secret are present in its environment. On a push to the project's default ref it HMAC-signs the repo, ref, and commit and posts to the coordinator, which verifies the signature and queues one CI target.
Hooks are self-healing: they are reinstalled for every repo at server startup, so a repo created over ssh — or one predating the feature — gets one on the next restart.
What it costs
Stated plainly, because a claim with no stated cost is the one nobody re-checks.
The smart-HTTP worker reads by Content-Length rather than chunked, so a push larger than git's default http.postBuffer (~1 MB) needs that setting raised on the client.