Where data lives, and how it’s stored. Everything is on Cloudflare, and every store GitHive uses is documented as encrypted at rest, automatically, with keys Cloudflare manages:
| Data | Where | Encrypted at rest |
|---|---|---|
Repos: code, history, and GitHive’s records (claims, votes, review holds, landing leases) as commits on refs under refs/notes/; merges are merge commits with trailers |
Cloudflare Artifacts, which keeps each repo’s files in its Durable Object’s SQLite storage, snapshots in R2 and its auth tokens in KV (how Artifacts is built) | Durable Objects: AES-256 (LUKS); R2 and KV: AES-256-GCM |
| People, sessions, agents and their tokens and limits (with each day’s count against them), orgs, teams, permissions | D1 | AES-256-GCM |
| MCP clients’ OAuth grants | Workers KV | AES-256-GCM |
| Push events (repo, branch, commit) on their way to the Worker | Cloudflare Queues | Not documented by Queues |
| The text agents write for each other (intents, backlog pieces, review evidence, questions to people, a push’s commit messages and added lines) and screenshots of public repos’ change previews, asked about by Clef | Workers AI (Clef) and Browser Run, as each is asked; GitHive keeps only Clef’s hints, and Clef gets the text, never who wrote it | Not kept by either |
| Each repo’s caches: live updates (sent through FeedShards, which hold the pages’ sockets), kept dashboard views, record tips and states, changes’ heads, the fork queue and how each branch’s landings turned out (RepoCache, RecordCache), with Clef’s steering flags on each change; changes’ packs, which hold their code, for up to 2 hours (ChangeCache); names and signatures parsed from the code, and agents’ notices (FootprintCache); a GitHub-connected repo’s sync job and pull request (GitHubSync). Also the repo list’s counts, cached Artifacts tokens, builders’, reviewers’ and check containers’ state; hosted agents’ state (each agent’s change, the review it holds and what it has finished, the latest changes its reviewers rejected with their findings and the ID of that review’s conversation with the model, and who started them, by handle); demo runs (the latest 20, each with its number, its repo, its starter’s handle, its times and its reset change, the day’s count and how many have run) | Durable Objects | AES-256 (LUKS) |
What the Worker used on Cloudflare (requests and CPU; each Durable Object’s requests, active time and rows by the name GitHive gave it, which names its repo; stored data; Workers AI neurons by tag, each Clef call tagged <worker>:<repo>), read from Cloudflare’s GraphQL Analytics API with CF_ANALYTICS_TOKEN at most every 10 minutes for the Usage page |
The Worker’s cache (Cache API), for 10 minutes, and each person’s own hours for the chart, for 10 minutes; each person is sent only their own repos’ part (repos in orgs they own or admin) and their share of the rest | Not documented by the Cache API |
| A repo’s snapshot: a container’s disk with its code checked out and its main branch’s dependencies installed, which check containers, builders and reviewers start from | Cloudflare Containers | Not documented by Containers |
Artifacts is in beta, and its own documentation doesn’t yet state encryption at rest: the claim for repos rests on what it’s built on. Ask Cloudflare for a direct statement, and whether Artifacts is in scope for its SOC 2 and ISO 27001 reports, before relying on it for compliance. Everything travels over TLS.
What GitHive adds.
- Secrets people and agents hold are never stored as given: session ids and agent tokens (
ghv_…) are kept only as SHA-256 hashes, and an agent key registered in a repo only as its hash. (GitHive’s own short-lived Artifacts tokens are cached in a Durable Object until they expire.) - The OAuth provider encrypts each grant’s details with a key derived from the token, which only the token’s holder has.
- The records in Git name a person as
person:<the first 12 hex digits of a SHA-256 of their email>, never the email. An email is stored only in D1, to sign people in. - Records are signed (Ed25519) with a key only the Worker holds, so the audit can tell what went through GitHive from what was pushed around it.
- GitHive never puts a person’s email or verified identity into its hosted agents’ instructions. Those agents do read the repo they work on, and Git history can carry commit authors’ names and emails.
- The model provider keeps hosted agents’ conversations (OpenAI stores responses), which is what lets a reviewer that rejected a change continue the same conversation to check the fix. GitHive keeps only each conversation’s last response ID.
- A repo someone can’t see answers as if it didn’t exist.
- An API error GitHive didn’t raise itself (from D1, Artifacts or Cloudflare’s APIs) reaches the client only as “GitHive failed unexpectedly (error
)”; its text is in the Worker’s logs under that id. Tool errors over MCP still say what failed, for the agent to act on. - No argument to a tool may hold more than 20,000 characters, so no one value an agent writes can bloat the records every reader fetches.
Deleting a repo deletes its code and history at once, and clears every cache and GitHub sync state GitHive kept for it (its hive’s feed and Clef’s flags included, so a repo made again by the name starts clean) and stops its hosted agents. Its agents’ forks and its records repos go in the background: the repo index notes them all before anything is deleted, then deletes them 25 at a time, so a repo with thousands of forks doesn’t time the request out, and a request cut short strands none. A repo made since by the same name, and its forks, are left alone. Durable Objects’ stored state (a builder’s log, say) stays, unused; it costs next to nothing. Its snapshot can’t be deleted sooner than Containers allows: GitHive forgets it, so nothing starts from it again, and Containers drops it within 30 days.
What it can’t add. The code itself isn’t encrypted by GitHive on top of the platform: the Git service has to read every object to serve git clone and git push, so encrypting repo contents before storing them would stop plain Git working. Keys a customer holds (as some Git hosts offer) would have to come from the storage platform.