KyGit“key-git” — the key stays with you

A Git remote that cannot read your code.

Your history is encrypted on your own machine before it leaves, under a key we never receive. Keep GitHub for the collaboration. Add KyGit as the second remote that no one else’s AI can read into — not even ours.

Do this: paste this into your coding agent’s chat.

Get started with kygit.com: read https://kygit.com/llms.txt and add KyGit to this repo as an encrypted second remote. Copy

Or do it by hand — two commands How it works

• Plain git push
• Open source, two independent verifiers
• Recoverable without us
• Free tier never expires

What we cannot do with your code

Most hosting pages list what the host can do. KyGit is defined by what it can’t. Each of these is a property of the design, not a line in a policy.

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.

And it is built for agents, not merely defended against them: your coding agent holds its own envelope and works normally — plain git, 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. One install, then two commands:

npm i -g run402            # one package
run402 repos create        # provisions the vault, scaffolds the run402:: 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 run402 repos create, then plain git push — is a first-class shape. No database, no manifest, nothing else to learn. Signing up as a human? Start on run402.com; the free tier is the same either way.

Built for agents, not just defended against them

Handoff. Resume. Invite. Join. — one agent hands off or invites; the other resumes or joins.

There is no separate KyGit API, CLI, or protocol — one machine surface, one vocabulary. An agent’s reference is run402.com/llms-full.txt (section “vault”, routes under /vaults/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.

What it costs

There is no separate KyGit price. A vault’s bytes count against a run402 tier’s own vault quota, separate from app storage: prototype is a one-time $0.10 testnet payment that never expires — 1 GB of vaults, unlimited repos, no lease to renew. Hobby is $5 for a 30-day lease with 10 GB of vaults; team is $20 for a 30-day lease with 50 GB. Vault bytes are 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, pathUSD on Tempo via MPP, or sats over Bitcoin Lightning via MPP.

Vault write routes are never lifecycle-gated at all — a vault’s only bound is its own quota above, never billing state, on any tier — and the mirror below means your history is never hostage to a billing state in the first place. If a leased tier’s lease lapses, excess capacity elsewhere on the org freezes in place (nothing deletes), and the org eventually returns to perpetual prototype rather than being purged.

Honest about the limits

“Is my code safe with you?” is several different questions with different answers, and conflating them is how hosting pages lie. Here they are, separately, with the limits attached to each.

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

The mirror is the recommended default, not a power-user extra: run402 repos create teaches it right beside the recovery receipt, and an unmirrored vault carries a standing, informational finding until a first mirror write or sync succeeds.

run402 repos mirror s3://your-own-bucket          # once; a local directory works too
run402 repos mirror --backfill                    # catch up; every capture writes the mirror 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 capture-time mirror write keeps yours current) — and a mirror multiplies where your ciphertext lives, not who can open it. Without your keys, mirrored ciphertext recovers nothing.

And if a copy in your storage is not enough, make your storage the primary: run402 repos create --byo s3://your-bucket/prefix allocates a vault whose payload ciphertext lives only in a bucket you own — for a BYO vault, your source ciphertext never touches our infrastructure — not even encrypted. We hold the small signed chain and nothing else, your client copies that chain into your bucket too, and the honesty inverts with the custody: run402 holds no payload copy of a BYO vault — only the small signed chain; your primary bucket is the sole copy of your source until you add a second customer-held location — so the standing unmirrored finding stays on until you add one. One trade rides with that custody: a BYO vault admits exactly one writer in v1 — its key envelopes live only in your bucket, whose credentials never reach us, so a handoff mint, an invite mint, and a developer-or-above member add on that vault are each refused by name rather than handing someone write authority they could not use.

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:

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.

Who is behind this — and why you don’t have to trust us

KyGit is built by Kychee, Inc., a small software company, as run402’s git vault under its own front door. We are not a tech giant, and a fair question is whether a small company should hold your code at all. Our answer is that the product is designed so the question does not arise: we cannot read what you push, we cannot hold it once you mirror it, and everything that lets you check those two claims is public.

• Open source, twice. The client is open source, and an independent-lineage verifier in Rust shares no code with it — so you never take our client’s word. How the two verifiers work.
• A published threat model. Every claim on this page is graded by strength, with its residual, in the threat model.
• A recovery drill against production. A real vault, mirrored, then recovered ref-exact with our gateway deliberately unreachable. The tool that did it is the one you get.
• Standard cryptography, nothing invented. Reviewed adversarially by two frontier models on opposite sides of the table; not yet independently audited by a third party, and we say so rather than imply otherwise. The review process.
• A live status page and a real address. status.run402.com, and who we are.