Plombir Git

A lightweight, self-hosted Git forge for teams where code is written by people and AI agents alike.

Built with codeindexer.dev: 1,294 commits in ten weeks, 1,167 bug tickets closed, 633 of them found next to another fix — how.

Plombir Git hosts repositories, issues, pull requests, code review, CI, a wiki and package registries — and treats an AI agent as a participant of its own: its own account, its own narrowed token, its own audit trail, while a person keeps the approval that opens the merge. One server process speaks Git over HTTPS and SSH and serves the REST API, MCP and the CI scheduler; the web UI is a static SvelteKit bundle served next to it. It sits in the same space as Gitea and Forgejo.

<p align="center"> <img src="docs/screenshots/agent-pr-demo.webp" width="880" alt="An AI agent's pull request in Plombir Git: the agent's bot account opened it and applied a reviewer's suggestion, and a second person approves and merges it"> <br> _{An agent opens a pull request under its own bot account and applies a review suggestion over MCP; a second person approves and merges it.} </p>

Origin. Plombir Git is a fork of IronForge. See NOTICE for provenance and licensing details.

---

Why Plombir Git

Three things, each with something you can check.

1. Agents work under their own name, and a person approves

• MCP is part of the server, at POST /api/v1/mcp, with the caller's credential and every access check of the REST API behind each tool call. There is nothing extra to install. (Gitea's MCP server is a separate program, gitea-mcp.)
• Any user can create a bot account they own. It has no password, it acts only through tokens you mint, and it stops working when your account does.
• Tokens can be narrowed to named repositories and named MCP tools, and kept off protected branches — on by default for a bot's token.
• A person opens the merge. A bot's approval never counts toward a protected branch's required approvals, nor does its owner's approval on the bot's own pull request. A bot cannot approve a protected deployment environment, and CI for a pull request from a fork runs only after a person approves its exact head commit. Working alone with your own bot, where no second person exists to approve: one person and their agent.
• Every MCP tool call is in the audit log (agent.mcp_tool_call), and so is every request a token's narrowing refused (agent.scope_denied).

Proof: the whole loop — an agent branches, commits, opens a pull request, answers review, a person approves — is an integration test and a recording, docs/demo/agent-review.cast (asciinema play docs/demo/agent-review.cast). Details are under MCP over HTTP and agent accounts.

Gitea 28 has bot accounts and an audit log too (release notes), so "has bots" is no longer the difference. The difference is who may create one, what its token can be narrowed to, and whose approval counts.

2. Release assets that can be verified outside the forge

With attestation_enabled = true under [releases], anyone with write access can have a release asset signed: POST …/releases/assets/{id}/attestation produces an in-toto Statement v1 in a DSSE envelope, canonicalised with RFC 8785 and signed with the instance's Ed25519 key. The public key is the one already published at /api/v1/ci/oidc/jwks, and …/attestation/verify checks an envelope on the server. The statement's predicateType is https://plombir.com/git/provenance/v1. It names the format, not the signer: predicate.builder.id is the issuing instance's URL. Envelopes issued before the rename carry https://forgekeep.dev/provenance/v1, the same format under the former name, and still verify.

What it states, precisely: this instance received exactly this SHA-256 for this release, from this uploader. It is not SLSA build provenance — it says nothing about how the file was built. The signing key is stored, not derived from jwt_secret, so rotating that secret does not invalidate signatures already issued (see Secrets and rotation).

3. CI that runs what you wrote, or refuses by name

Plombir Git runs .gitea/workflows/*.yml as a strict subset of Actions. A key it accepts is executed; a key, trigger or action it does not implement fails the whole workflow with a message naming the file, the job and the key. It is never quietly dropped, so you never get a green run of a shortened workflow. A protected environment: holds the job until a person approves it.

The table below is the honest trade. Gitea runs much more of the Actions ecosystem; Plombir Git's promise is narrower and stricter.

A look around

<table> <tr> <td width="50%"><a href="docs/screenshots/pull-request.webp"><img src="docs/screenshots/pull-request.webp" alt="A pull request opened by a bot account, marked BOT and on behalf of its owner, with its Markdown description rendered"></a><br>_{<b>Pull request from an agent.</b> The bot account is marked, and so is the person it works for.}</td> <td width="50%"><a href="docs/screenshots/review-suggestion.webp"><img src="docs/screenshots/review-suggestion.webp" alt="An inline review suggestion on a diff line, applied by the agent, with its reply in the thread"></a><br>_{<b>Code review.</b> Inline comments and suggestions; the agent applies one and answers in the thread.}</td> </tr> <tr> <td><a href="docs/screenshots/pipeline.webp"><img src="docs/screenshots/pipeline.webp" alt="A CI pipeline with lint and test stages, every job passed"></a><br>_{<b>CI.</b> Stages, jobs and logs from <code>.plombir-git-ci.yml</code> or <code>.gitea/workflows</code>.}</td> <td><a href="docs/screenshots/audit-log.webp"><img src="docs/screenshots/audit-log.webp" alt="The audit log listing agent.mcp_tool_call entries for the bot account next to the people's actions"></a><br>_{<b>Audit log.</b> Every MCP tool call an agent makes is recorded.}</td> </tr> <tr> <td><a href="docs/screenshots/repository.webp"><img src="docs/screenshots/repository.webp" alt="A repository page with its file tree, recent commits and rendered README"></a><br>_{<b>Repository.</b> Code, branches, releases, packages and a wiki.}</td> <td><a href="docs/screenshots/issues.webp"><img src="docs/screenshots/issues.webp" alt="An issue list with labels and a milestone"></a><br>_{<b>Issues.</b> Labels, milestones, assignees and boards.}</td> </tr> </table>

The screenshots come from a local demo instance with made-up users and a made-up project.

Actions compatibility

Compared with Gitea 28.0.0 and Gitea Runner 2.0.0, as of 2026-10-03. Gitea documents its Actions as GitHub-compatible except for the differences on its comparison page; a ✅ in the Gitea column means the key is not listed there, or that the release notes cited in the row added it. Plombir Git's side is specified in full in docs/gitea-actions.md.

| Workflow syntax | Plombir Git | Gitea 28 | |-----------------|-----------|----------| | on: push, pull_request, workflow_dispatch, workflow_call | ✅ | ✅ | | on: schedule, pull_request_target; on.<event>.types | ❌ refused by name | ✅ | | Branch, tag and path filters, ! negation | ✅ GitHub globs; +, ? and […] refused rather than read differently | ✅ | | concurrency (workflow level) | ✅ group, cancel-in-progress | ✅ since 1.26 (notes) | | jobs.<id>.timeout-minutes | ✅ | ✅ with Runner 2.0 (notes) | | jobs.<id>.continue-on-error | ✅ | ✅ with Runner 2.0 and Gitea ≥ 1.27 | | jobs.<id>.environment | ✅ an existing environment; a protected one waits for a person's approval | ⚠️ ignored | | needs, if, env, defaults.run.working-directory | ✅ | ✅ | | strategy.matrix | ✅ static | ✅ static and dynamic | | strategy.fail-fast, strategy.max-parallel | ❌ refused | ✅ | | Reusable workflows | ✅ same repository only | ✅ | | container.image, container.env | ✅ | ✅ | | container.options | ❌ refused — it could undo the job sandbox | ✅ | | services: | ❌ refused | ✅ | | uses: actions | ⚠️ actions/checkout, actions/cache, actions/upload-artifact only | ✅ any action | | Composite actions, step id and outputs | ❌ refused | ✅ | | Step continue-on-error, step timeout-minutes, step shell | ❌ refused — a job's steps run as one script | ✅ | | permissions, vars.* | ❌ refused | ✅ |

If your workflows lean on marketplace actions, services or step outputs, Gitea will run them and Plombir Git will not. Plombir Git also has its own pipeline format, .plombir-git-ci.yml, for what the subset cannot express.

Memory: measured

We publish only numbers we measured:

| Build | Load | VmRSS at idle | VmHWM (peak) | |-------|------|-----------------|----------------| | 1e3679f, before the fix below | Production instance: 40 days up, 4 users, 35 MB database, 14 MB of repositories | 1.21 GB | 2.56 GB | | Build of 2026-10-06, with 1068860 | The same production instance: 9.8 days up | 258 MB | 395 MB |

1.14 GB of the first idle figure was 31 glibc per-thread malloc arenas of about 58 MB each, held fully resident by transparent huge pages. Since 1068860 the server caps glibc at two arenas before it starts its worker threads (an explicit MALLOC_ARENA_MAX still wins). On the same host, still with transparent huge pages set to always, that is 4.7 times less at idle and 6.5 times less at peak; 178 MiB of the idle figure is in huge pages (AnonHugePages). Both rows are read from /proc/<pid>/status of the running server.

How it is built

Plombir Git is developed with AI coding agents. They write the code; the maintainer decides what to build and reviews it. The repository's pre-push hook (.githooks/pre-push) lets a push through only once scripts/verify-push-gates.sh has passed on that exact commit:

• cargo fmt --check, workspace Clippy and cargo doc, where a warning is a failure;
• around eighty scripts/*-contract-check.mjs checks that pin documentation, configuration, routes and access rules to the code;
• Docker Compose, observability-config and frontend checks.

The workspace test suite — 3,440 tests on 4 October 2026, about six minutes under cargo nextest on a warm build — is not part of that push gate; it is run before a piece of work is closed.

Built with codeindexer

The agents that write Plombir Git work through codeindexer.dev: an index of the code with search and a call graph, plus a memory that outlives a session — tickets, roadmap phases and notes on solved problems, shared by every agent on the project.

Every ticket goes through the same loop. Find the code through the index, check who calls it (find_callers, find_references) before changing it, fix it. Then ask where else the same construct lives — another parser, cache or call site — and file a ticket for each real hit, under the roadmap phase for its class of defect rather than the one being worked on. A non-obvious cause goes into the solutions base, so the next session finds it in seconds instead of rediscovering