Git for things you cannot put on GitHub: what an encrypted vault is

There is a category of file with nowhere good to live: a risk register with real system names, an analysis still being argued about, the working memory of an agent that has read your codebase for a month, client material under NDA. It wants history, branches, diffs and a link, and it is the reason people say 'we can't put that in GitHub', so it ends up in a shared drive or a thread nobody can diff. sgit is git for those files: encrypted before they leave your machine, versioned like git, stored on a server that holds ciphertext and nothing else, not filenames, not directory structure, not commit messages. There is no key escrow, no admin override and no support engineer who can recover it, which is a feature with a real cost.

Decided by. Nobody yet: a candidate for Dinis to read, comment on and decide (keep, rewrite, merge, cut, article first, later, not doing it).

Note. Dated 25 August 2026. The evidence in the article: an object is 786 bytes of AES-256-GCM ciphertext named by the SHA-256 of the encrypted bytes, so the host can deduplicate it, cache it and serve it from a CDN without knowing what it is; all nineteen published vaults cloned from their published keys, 1,389 files, no failures. Underneath it is real version control (multi-parent commits, a tree per directory, merge-base, three-way merge), not a sync folder. Status, plainly: sgit is beta and says so on every page; pip install sgit-ai, pure Python, two runtime dependencies, Apache-2.0. The then-and-now for the 2018 Backup your life: back up into a vault whose key you hold.

Where it comes from

Git for things you cannot put on GitHub the opening; The part that is easy to say and hard to build (newsroom)

What it answers in the 2018 book

Backup your life answered written, Life Patterns

Where it goes

Chapter Privacy by design: SG/Send, sgit, and the value of constraints, part Build it without a server (drafting); topic Building blocks: cloud, serverless, free models, git and CI.

Other ideas proposed for the same chapter: One string is address, authorisation and key; the read key derived from it is safe to publish, An app in a vault runs against the vault without ever being handed a key, Encryption on the client moves the problem from the data to the keys, and the sovereignty line to whoever holds them, Where the keys live: a password manager for the keys a person holds, a registry vault for the keys agents make, Append lanes: one POST from anywhere, readable only by the vault's owner, Nobody buys it for the encryption: the features came from the constraint, Client-side encryption reduces the exposure under GDPR; it does not take you out of it.

Node idea:git-for-things-you-cannot-put-on-github in graph.json; see it in the graph. Source: admin/content/graph/ideas.json.