BYOK connections and security

BNLGit never bills you for LLM usage. You bring your own provider keys — "BYOK" — under Settings → Connections & BYOK, and your model spend stays a matter between you and your provider.

Connection types

LLM connections — used for summary generation and, on Pro, cleanup analysis:

Git connections — for pulling from elsewhere: github, or git_host for another Gitea-compatible host.

Saving a connection

Save it, press Verify, then press Refresh models.

Refreshing pulls the model catalogue from that connection and BNLGit will only let you select a model that the catalogue actually returned. A pairing can never fall back to a guessed model ID.

How secrets are protected

Connection secrets are encrypted at rest with AES-256, under a dedicated BYOK_SECRET_KEY held by the instance operator. That key is deliberately separate from Gitea's general-purpose SECRET_KEY, which protects unrelated things like two-factor secrets and webhook signing — so the blast radius of the two is not shared.

If BYOK_SECRET_KEY is not configured, BNLGit refuses to save or read any connection secret rather than silently falling back to another key. Connection secrets either use their own dedicated key, or the feature does not work.

The plaintext secret is never serialised into an API response. Only a masked hint is ever returned, and credential references are exposed only to repository admins and site admins.

Key rotation is supported: bnlgit admin regenerate byok-credentials re-wraps stored secrets onto the current key.

Outbound requests are restricted

When BNLGit calls out to a connection's endpoint — to verify it, fetch its model catalogue, or generate a summary — the request is blocked from reaching loopback addresses, private IP ranges, link-local addresses, and cloud metadata endpoints, regardless of what the connection's endpoint URL claims to point at.

Point connections at real, reachable provider hosts. This restriction is not configurable by tenants, and that is the point of it on a shared service.

What this means practically

• Your keys pay for your summaries, on your repositories. There is no shared pool and no cross-tenant spend.
• You can revoke at your provider at any time and BNLGit degrades to "cannot generate" rather than to some fallback of ours.
• Deleting a connection stops future spend. Summaries already generated are files in your mirror repository and remain yours.

See also Managed worker and spend controls for the budget ceilings that sit on top of all of this, and Security and data handling for the wider picture.