hushgit join waitlist

Customer-controlled CI for encrypted repos

CI has to decrypt source code to build it, so HushGit uses runners you control instead of managed build workers.

Why managed CI is out of scope

A hosted runner that sees plaintext code becomes part of your source-code trust boundary. HushGit avoids pretending otherwise: the integration path is bring-your-own runner, explicit runner authorization, transparency-verified job state, and auditable decrypt permissions.

Runner flow

  1. A repo owner signs a runner registration intent and shares its pairing code with the operator who will host the runner.
  2. The runner machine generates Ed25519 signing and X25519 wrapping keys locally, encrypts them with a passphrase-derived envelope, and posts a signed claim plus the pairing code.
  3. The owner verifies the runner fingerprints, signs approval over the exact runner keys, and exports owner-controlled repo content key material for the runner host.
  4. A native-trusted device signs an encrypted runner job that pins an encrypted spec chunk, allowed runners, lease duration, and timeout; the response includes the current repository transparency proof.
  5. The runner continuously polls with a fresh signed claim, verifies each owner-signed job envelope against trusted owner keys, verifies the repository transparency proof against its trust anchor and local pin, and sends running heartbeats under an active lease.
  6. Under that lease, the runner fetches proof-bearing encrypted spec, manifest, and Git pack chunk bytes by known ids; the server cannot inspect the manifest plaintext.
  7. Material is decrypted into a per-attempt workspace; the pinned commit is checked out into a temporary bare mirror with inherited Git config, hooks, and filters disabled, and spec steps run from the checkout.
  8. Bounded combined logs and declared artifact files are sealed as encrypted result chunks, uploaded under the lease, and referenced from an encrypted result summary chunk named in the runner-signed terminal completion with the current repository proof.
  9. Owners can cancel queued or active jobs and revoke runner keys with native-trusted signed actions; canceled or revoked runners can no longer heartbeat, fetch material, upload results, or complete.

Non-goals for the first runner

The CI model excludes hosted runners, server-side checkout, server-side artifact inspection, and server-side logs that contain plaintext code.