Skip to content

The Forge & trust

A Forge is the optional collaboration server where teams sync and review work. It hosts collaboration state, audit views, agent coordination, CI integration, and the always-on peer that repositories can sync through.

The load-bearing distinction from a conventional Git host is narrower than “trustless hosting”: the Forge stores policy-protected objects as ciphertext and does not receive recipient private keys or unwrapped data keys merely to host them. It still controls service availability, sees public content and collaboration metadata, enforces write-side gates, and can participate in explicitly authorized runner or agent disclosures.

Phase note

The single-node Forge, both sync transports, authenticated REST, collaboration state, policy/review gates, locking, events, administration, backup, metrics, org policy, and server plugins are built and hermetically tested. Production binaries have passed the documented distinct-Docker-host exercise under a real operator CA. Broader distributed, physical, HA/load, hosted-parity, and release evidence remains open, and the hosted TOVIO Cloud service is not yet generally available.

What the Forge stores

The Forge owns mutable collaboration state around the immutable object graph:

  • Proposals and reviews — the change-review lifecycle (draft → open → approved → landed).
  • Webhook subscriptions and CI/CD integration.
  • Agent-session and coordination state — including provenance and overlap information.
  • File locks, audit context, and org/repository administration.
  • The repository object graph — public objects in clear form and policy-protected payloads as ciphertext.

The Forge is a distribution and coordination layer, not the sole read-permission boundary. It remains a security boundary for availability, integrity, metadata, administration, write policy, and authorized disclosure edges.

The stored-object boundary

What storage alone cannot decrypt

For a policy-protected object, the Forge object store holds ciphertext and no recipient private key or unwrapped DEK. Compromising only that stored object/API view does not directly produce its plaintext.

This statement does not cover a compromised authorized endpoint, Key Authority mis-issuance in Tier 1, a runner or agent explicitly given plaintext, or plaintext disclosed outside the TOVIO read path.

What the Forge can see

Public objects are clear, as on a conventional Git host. The Forge also sees repository and collaboration metadata: paths and object relationships exposed by an authorized projection, proposals, review decisions, agent sessions, locks, audit context, administration, and service traffic. Authorized runner inputs and explicitly disclosed agent context have separate boundaries.

Protection is enforced by encryption of the stored object, not only by a server access check. An authorized client still materializes plaintext in a working copy, and approved runners or agent sessions may receive disclosed context. Those endpoints must be secured separately. In Tier 1, the Key Authority is also trusted not to add an unauthorized recipient; the permissions model documents that residual risk.

Review without server-side decryption

A reviewer's clearance may be narrower than a change's file set. The Forge serves the objects and the proposal state; the review itself is rendered at the reviewer's endpoint — today tovio review in the CLI — with the reviewer's own keys:

  • For files the reviewer can decrypt, the client renders the diff normally.
  • For files the reviewer cannot decrypt, the client renders a redacted entry — the path plus a coarse marker for whether it was added, changed, or deleted — never the plaintext or a content diff.
  • Unreadable files do not block the review: the reviewer approves the portion they can see, and that decision is recorded whether or not they could read every file.

On a lane that requires review, a separate server-side gate decides whether the proposal may advance. When the proposal is marked approved, and again when it lands, the Forge recomputes from its own objects, policy manifest, and roster which protected read policies cover the paths that advancing the lane would introduce — a set that includes paths inherited from a stacked ancestor, not only the ones this change edited. Every one of those policies needs at least one approving reviewer who can read it, or the transition is refused. The guarantee is about the approving set, not about who may press approve: a non-recipient's approval is still accepted and recorded, it simply cannot cover a policy on its own.

Redaction is not a built Forge route: the server never substitutes its own read authority for the reviewer's. This keeps the stored-object confidentiality boundary separate from the endpoint that legitimately materializes plaintext.

Why running your own Forge still matters

Running the Forge yourself lets an operator control service metadata, availability, network policy, administrative access, backups, and disclosure edges. Encryption reduces how much the object-storage operator must be trusted with policy-protected payloads, but it does not make the operator irrelevant: the host can deny service, observe metadata, expose public content, tamper until verification rejects it, or target authorized endpoints.

Mental model

A collaboration server whose object store receives ciphertext for protected payloads. Treat it as trusted for operations and metadata, while recipient keys and plaintext materialization remain client-side boundaries.

The boundary in one table

Conventional Git host TOVIO Forge
Read-confidentiality basis server-side access rules encrypted protected objects plus recipient keys at authorized endpoints
Object store contents commonly plaintext repository content protected payload ciphertext; public content and metadata remain visible
Storage/API host compromise may expose hosted plaintext does not directly decrypt protected objects, but exposes visible data and can target disclosure endpoints
Authority role usually central read/write authority write/admin authority; Tier-1 KA separately controls recipient wrapping and is trusted not to mis-issue
Operator trust still required for content, metadata, integrity, availability metadata, integrity, availability, administration, and disclosure-edge operation

Where to go next

Last reviewed September 9, 2026

Suggest an improvement to this page Not for security reports — see disclosure