KyGit

A Git remote, encrypted before it leaves your machine. Pronounced “key-git” — the key stays with you.

Built for your agents. Unreadable to everyone else's.

KyGit is a git vault — run402's client-side-encrypted Git remote — under its own front door. You push with plain git push, and your history is encrypted on your own machine first, under a key we never receive. Run402 cannot decrypt your gitvault or repository history. So there is nothing on our side to read, to index, to train a model on, to sell, or to hand to whoever asks next — not because we promise not to, but because we cannot. We hold no key to change our minds with.

How, exactly? The cryptography, the two independent open-source verifiers, and a security FAQ answering every attack vector we designed against are on the how-it-works page.

Your code host is an AI company now

Every major code host today belongs to a company whose models get better when it reads code. That is not an accusation about any particular host; it is a conflict of interest built into ownership — and ownership changes. Under a future policy, an acquisition, a training pipeline, a subpoena, or a breach, readable code is usable code, by anyone who can read it. KyGit's answer is structural rather than contractual: our future policies about your code cannot matter — including a future us, after an acquisition — because we never held the plaintext to change our minds about.

And it is built for agents, not merely defended against them: your coding agent holds its own envelope and works normally — plain git, a funded allowance, no dashboard, no human in the loop. Everyone else's AI — including ours — sees ciphertext.

Keep GitHub. Add the remote it can't read into.

You do not have to move anything. Keep GitHub or GitLab as your primary — collaboration, CI, reviews, pull requests, all unchanged. Add KyGit as a second remote: a complete, continuously updated copy of your Git history that the storage provider itself cannot read. Two commands:

npm i -g @kychee/kygit
kygit create               # provisions the vault, scaffolds the remote
git push origin --all      # encrypted on your machine, published as a signed head
local repo
  → GitHub / GitLab (primary — collaboration, CI, reviews, unchanged)
  → KyGit          (encrypted second remote — the copy nobody can read)
  → your keys      (backed up independently — they ARE the vault)

repos create allocates the vault immediately and prints the recovery receipt once; the first push admits generation 1. Or start clean: a vault-only project — one kygit create, then plain git push — is a first-class shape. No database, no manifest, nothing else to learn.

Durable, recoverable — and honest about the difference

“Is my code safe with you?” is three different questions with three different answers, and conflating them is how hosting pages lie. Here they are, separately.

The bytes: storage-grade durability

Your ciphertext rests in AWS S3 — storage designed for eleven nines of object durability — in a dedicated vault bucket whose policy, enforced by AWS rather than by our application code, requires create-only writes and refuses bulk deletion. Nothing in storage is mutable, so corruption cannot hide behind an overwritten object; it can only appear as a loud, detectable gap. And our database is not needed for disaster recovery: every admission is a signed, immutable record stored in the bucket itself.

Your history: recoverable without us

With the opt-in mirror, your history does not even have to rest only with us. Your ciphertext replicates to a bucket you own. We can't decrypt your repository history — and we can't hold it either.

run402 repos mirror s3://your-own-bucket          # once; a local directory works too
run402 repos mirror --backfill                    # catch up; every snapshot dual-pushes after
run402 repos recover ./mirror --out ./restored    # the drill — no server involved

If we disappeared tomorrow, your repository is recoverable from a bucket listing and your keys, with an open-source tool. No server required. Provable, not promised. We proved it against production: a real vault, mirrored, then recovered ref-exact with the gateway deliberately unreachable. Every prune requires receipts from two independently built open-source implementations — one in TypeScript, one in Rust.

The honest limits: offline recovery proves validity, never freshness — a stale mirror is indistinguishable from a short history (the dual-push keeps yours current) — and a mirror multiplies where your ciphertext lives, not who can open it. Without your keys, mirrored ciphertext recovers nothing.

Pushing right now: stated straight

Pushing to KyGit needs KyGit up — we will not pretend otherwise. What is structurally true: the byte path has no git application server in it. Your repository ciphertext moves directly between your machine and storage — our servers never handle it. Our control plane only admits signed heads — a far smaller surface than a whole forge. And your commits are local anyway, so a second remote in a separate failure domain turns someone else's outage into a non-event: when your primary host is down, this one keeps taking pushes — and the other way around.

Retention, in the same voice: unreachable history — dropped or force-displaced tips — is recoverable for at least 90 days, and every deletion is two-phase, attested, and attributable. Against a dishonest host that binds nothing, and we will not pretend otherwise: retention is an operational promise of the platform, not a cryptographic guarantee against it. What the protocol does instead is make silent loss loud — a prune that was not owner-authorized leaves a ledger gap your own client detects.

What we can see

Content is hidden; structure is not. This is not zero-knowledge hosting, and the honest way to say so is to enumerate the boundary: in the vault lane, source payload and repository-history content are ciphertext-only; the substrate retains only enumerated plaintext metadata and holds zero vault keys. We see that a vault exists and whose it is, ciphertext sizes and ids, generations and cadence, access times. We do not see branch names, commit messages, file paths, commit ids, or any un-keyed digest of plaintext. The full observer-by-observer boundary — and every claim on this page, graded — is enumerated on the full technical page and in the threat model.

Keys, teammates, and losing yours

A product whose confidentiality rests on the platform holding zero vault keys has, by construction, no platform-side rescue for lost keys. So the durability sentence carries its qualifier in the sentence itself:

The durability sentence

The vault protects source history from host-side loss while a principal keystore survives.

Every vault starts with exactly one keystore that can open it, and the client says so to your face — run402 repos view prints, verbatim:

whole-machine or whole-keystore loss is terminal for vault history
until human envelopes ship

It does not have to stay that way. Membership entails custody — a teammate who can read the code can recover the history. Adding a recipient ships today, end to end: a teammate enrols their own encryption key, a key-holding client wraps the vault key to them on its next push, and from that point losing one keystore no longer loses the history. Taking a reader away is live too, via epoch rotation — forward-only, which is stated rather than hidden: no rotation, here or anywhere, unshares what someone already fetched. Two practical consequences: back up your keystore, and cover a second principal. The full what-survives-what table is on the full technical page.

What it costs

There is no separate KyGit price. A vault's bytes count against the organization-pooled storage of a run402 tier — prototype $0.10 for 7 days, hobby $5 for 30 days with 1 GB, team $20 for 30 days with 10 GB — billed with a 1 MB per-vault minimum, so a small vault reads as roughly the minimum. Humans pay by credit card via Stripe; agents pay with USDC on Base via x402 or pathUSD on Tempo via MPP.

If a lease lapses: read-side vault routes are never lifecycle-gated — a vault stays readable while its organization is in billing grace — and the mirror above means your history is never hostage to a billing state in the first place.

For agents

There is no separate KyGit API, CLI, or protocol — one machine surface, one vocabulary. Your reference is run402.com/llms-full.txt (section “gitvault”, routes under /gitvault/v1); the CLI family is run402 repos; the wire protocol is r402s/v0. Run npx run402 repos --help to see what your installed client carries.