01 Host read path
The platform is inside the trust boundary.
Access controls protect you from other users. They do not remove the host, its employees, its tokens, or its internal services from your source-code threat model.
Zero-knowledge Git hosting
Your code stays encrypted. Your devices stay in control.
Private repositories should be private from the platform, too. HushGit encrypts code and review data on trusted devices before upload, so the server stores ciphertext—not your source.
Private alpha · every request is reviewed by a human
- Encrypted before uploadRepository content stays private.
- Signed device authoritySensitive writes stay native.
- Verifiable historyWitnesses defend against split views.
Encrypted workspace Proof verified
Desktop + CLIkeys and trusted writes
Browserconvenient review access
Your runnerself-custodied CI
why the boundary matters
Private by policy is not the same as private by architecture.
Traditional hosts hide code from other users, but the infrastructure that stores, indexes, reviews, and serves it can still read every byte.
02 Breach afterlife
A host breach outlives containment.
Copied source gives attackers permanent time to study auth paths, service boundaries, CI conventions, tests, and forgotten code that may still run.
03 Legal plaintext
Legal requests can reach readable code.
Subpoenas, warrants, foreign jurisdictions, and NSLs do not require your cooperation if the platform already holds both ciphertext and keys.
Recent evidence
Strong incident response cannot remove a structural read path.
May 2026 · GitHub internal repositories
Source exposure becomes durable attacker research.
GitHub says it is investigating unauthorized access to internal repositories after an employee-device compromise involving a poisoned VS Code extension, with no evidence that customer repositories were affected. The distinction matters—and so does the permanent value of copied platform internals.
Read GitHub’s updateMarch 2026 · CVE-2026-3854
A backend bug can become a source-code exposure bug.
GitHub validated and fixed the git push pipeline RCE quickly and reported no customer-data exfiltration beyond researcher testing. The architectural lesson remains: a server that can read private repositories makes readable source part of the blast radius.
Read GitHub’s post how hushgit works
Encrypt before push. Verify and decrypt after pull.
Plaintext lives on trusted devices and customer-controlled runners. Everything that crosses the host boundary is signed ciphertext.
Trusted
Your device
- Repository key
- held locally
- Source code
- readable
- Writes
- signed
Untrusted
HushGit server
- Objects + refs
- ciphertext
- Repository key
- never held
- Current state
- witnessed
Trusted
Teammate
- Device key
- unwraps access
- Source code
- readable
- Server state
- verified
Keys
Per-repository content keys
A symmetric key per repository, wrapped to each member’s device keys. Membership changes and rotation stay signed and auditable.
Review
Encrypted pull requests
Diffs are computed by your client. Comments, threads, and approvals are readable to your team and opaque to the platform.
Proofs
Witnessed server state
Trusted reads are checked against signed checkpoints, witness quorum, subject proofs, private openings, and local pins.
CI
Self-custodied runners
Code is decrypted only on compute you control. HushGit does not place readable source in a managed build worker.
the honest limits
We show the rows that cryptography cannot solve.
A threat model earns trust by being explicit about its edges. These are the promises HushGit makes—and the ones it does not.
Storage or database compromise
An attacker gets ciphertext blobs. Repository contents remain unreadable without device keys.
Backend RCE with trusted clients intact
Repository keys never touch HushGit servers. Decryption stays in signed native clients.
Backend RCE plus web app tampering
Pure-web clients remain vulnerable to malicious JavaScript from a compromised origin. Use the signed desktop app or CLI for sensitive repositories.
Server split view
Witnessed checkpoints and local pins make hidden forks detectable unless the attacker also defeats the witness quorum or permanently isolates the client.
Hosted CI/CD compromise
CI must decrypt to build. HushGit therefore supports customer-controlled runners only.
Malicious or revoked collaborator
A collaborator who legitimately had a repository may retain it. Rotation protects future content, not past access.
Platform comparison
Where code platforms actually stand on encryption. Including where alternatives beat us.
A buyer in this audience is mentally building this table anyway. We'd rather build it for you, honestly, with the rows you actually care about.
| Capability | Us HushGit | GitHub Private | GitLab self-managed | git-crypt | git-remote-gcrypt | Keybase Git | GitCellar |
|---|---|---|---|---|---|---|---|
| Confidentiality | |||||||
| File contents encrypted at rest, end-to-end | yes | no | no | yes | yes | yes | yes |
| Commit messages, refs, branch names encrypted | yes | no | no | no | yes | partial | yes |
| PR / code review encrypted end-to-end | yes | no | no | n/a | n/a | n/a | n/a |
| Review comments & threads encrypted | yes | no | no | n/a | n/a | n/a | n/a |
| Trust model | |||||||
| Server can decrypt your code | no | yes | yes | no | no | no | no |
| Provider staff have technical read access | no | yes | partial | no | no | no | no |
| Survives a backend RCE | yes | no | no | yes | yes | yes | yes |
| Subpoena yields readable code | no | yes | yes | no | no | no | no |
| Witnessed split-view defense for hosted state | yes | no | partial | n/a | n/a | partial | no |
| Workflow | |||||||
| Incremental push (no force-push on history) | yes | yes | yes | yes | no | partial | partial |
| Modern PR review UI | yes | yes | yes | no | no | no | no |
| Built-in key rotation & revocation | yes | yes | yes | partial | no | partial | partial |
| Audit log of access changes | yes | yes | yes | no | no | no | no |
| CI / build | |||||||
| Source code leaves your control for CI | no | yes | partial | n/a | n/a | n/a | n/a |
| Customer-controlled runners only (by design) | yes | no | partial | n/a | n/a | n/a | n/a |
| Transparency | |||||||
| Proof-bearing API responses and offline evidence | yes | no | partial | n/a | n/a | partial | no |
| Release / web build transparency | partial | no | partial | partial | partial | no | partial |
| Warrant canary | yes | no | no | n/a | n/a | partial | n/a |
● yes
◐ partial
○ no
last updated 19 june 2026 · we keep this honest
※ git-crypt, gcrypt, and the public GitCellar crypto repo are encryption building blocks rather than full code platforms — review, collaboration, and access management still happen elsewhere on your unencrypted code. We score them ✓ where they apply and "—" where the row is out of scope. Keybase Git pairs E2EE git with a Merkle tree anchored to a public blockchain, so it earns ◐ on split-view detection; HushGit differs by using an independent witness quorum and proofs bound to live repo and account state rather than a single self-published log.
built for high consequence code
For teams whose code is the company.
HushGit is designed for small, security-conscious teams who value a narrow trust boundary more than an endless marketplace of server-side integrations.
AI labs
Model code, training pipelines, and evaluation harnesses—the IP your company is built around.
Crypto and wallets
Signing logic, custody flows, and trading strategy where a source leak can become a live exploit.
Defense-adjacent teams
Dual-use software, autonomy stacks, and export-sensitive projects that demand a smaller read path.
Regulated startups
Healthcare, finance, and legal-sensitive code where a host incident becomes a board-level event.
why we are building this
We are building for the day your host is the headline.
A “private repository” is still readable to the infrastructure that stores and serves it. Platform source exposure gives attackers a durable map of that infrastructure. HushGit removes the server from your source-code read path.
We are a small security-focused team building zero-knowledge Git as a product, not a paper. No managed CI ambitions. No machine learning on your code. No hidden plaintext persistence.
- Proof-bearing open protocol
- Reproducible builds planned
- No telemetry by default
questions to ask first
The questions your security review should ask first.
Clear answers about keys, clients, CI, recovery, and failure modes—before you trust us with a repository.
Is this just git-crypt with a website?
No. git-crypt encrypts selected files, not metadata, refs, commit messages, or PR review state. We encrypt the whole workflow.
How is this different from git-remote-gcrypt?
gcrypt works but treats every push like a force-push and re-uploads on history growth. We use modern E2EE-Git constructions with incremental, content-addressed encryption.
How is this different from GitCellar?
GitCellar's public repo is a crypto/chunking library for backing up Git bundles. We specify a full hosting protocol: signed event log, witnessed transparency proofs, encrypted PR review, browser/native authority split, and customer-controlled CI runners.
Can the server show different histories to different users?
Current server-backed state is verified against witnessed checkpoints, subject-map proofs, private openings, and local pins. A hidden split view needs witness-quorum failure, witness rollback, or permanent isolation from honest monitors and peers.
Can you run on our infra?
Self-managed deployment comes after the cloud alpha. The crypto is the same either way; we don't have keys in either deployment.
Will there be managed CI?
No. CI has to decrypt source code to build it, so HushGit integrates with customer-controlled runners instead of hosted build workers.
What about Copilot-style assistants?
Not on roadmap. Sending your code to a model provider would defeat the entire point.
Pricing?
Per-seat, per-repo, with a free tier for small teams once we exit alpha. Founders get grandfathered pricing.
Private alpha
Keep company-defining code outside the host’s read path.
Tell us where today’s private repository model falls short. We review every request and write back personally.
No marketing list · no automated sequence · no telemetry