Bundle locally
Create a standard snapshot from the repository you control. Working-tree paths and project names do not become Gate routing labels.
Portable encrypted repositories · repository verification
Your repository stays Git.
Your storage provider does not read it.
DaemonGit publishes a normal Git bundle only after client-side authenticated encryption, then distributes the encrypted bytes as erasure-coded DaemonCloud shards. Recovery produces a standard bundle that ordinary Git can verify, clone, and archive.
Current truth: bounded bundle publication/export, encrypted sharded storage, and capability-bound collaborator fetch are repository implemented under verification. This page is not a live hosting offer. A Git remote helper, incremental fetch/push negotiation, multi-writer forge, CI or AI execution service, and public source projection are planned—not implemented product claims.
One portable object
Encrypt the bundle—not Git itself.
A local repository creates a bundle containing ordinary objects, refs, pack data, signatures, and history. The client protects that bundle with repository-scoped key material before any storage participant receives bytes.
DaemonCloud then handles availability: authenticated ciphertext is chunked and erasure-coded across the exact Gates selected by its signed grant. Gate loss is survivable only while enough authenticated shards remain.
Encrypt locally
A repository epoch key protects the bundle before sharding. DaemonSeed and DaemonGates do not receive that key.
Distribute ciphertext
DaemonCloud places authenticated erasure fragments under one bounded, owner-authorized storage grant.
Export normal Git
The owner recovers and authenticates the encrypted object, writes a standard bundle, then uses ordinary Git tooling.
Compatibility, not lock-in
The recovery artifact is not useful by itself: storage authority and the sealed repository state are both required. Once the bundle is legitimately exported, DaemonGit cannot revoke copies another Git client retained.
Separated authority
Reading source is not permission to mutate storage.
The storage-owner key remains the only authority for putting and deleting the DaemonCloud object. Repository epoch keys are separate. Any collaborator path must be an explicit, repository-scoped delegation rather than a network pass, payment receipt, or claimed Persona relationship.
Storage owner
Signs exact storage operations. This key is not handed to a collaborator, runner, indexer, or forge interface.
Repository epoch
A fresh repository-scoped key protects source for one access epoch. Rotation limits future access; it cannot retract code already disclosed.
Recipient capability
A pairwise descriptor and explicit permission can scope one recipient without becoming global identity or project membership.
Exact fetch
The repository Gate path accepts recipient-signed delegated reads only for one exact snapshot and shard. It does not grant put, delete, movement, or grant-creation authority.
Product status
A storage lifecycle is not a software forge.
The repository foundation can prove portable bundle publication and recovery. A complete collaboration system needs stronger shared-state, identity, execution, and operational contracts that are deliberately not inferred from encrypted storage.
Portable bundle and delegated read
Create a normal bundle, encrypt and shard it, recover it, or give one pairwise recipient fetch-only access without disclosing the storage mutation key.
PORTABLE SNAPSHOT PATHGit remote helper
No daemon:// clone command, incremental pack negotiation, transparent fetch, or push adapter is currently claimed.
Multi-writer forge
Branches, issues, reviews, merge requests, ref compare-and-swap, conflict resolution, and a browser forge need a non-equivocating collaboration design.
NOT IMPLEMENTEDCI execution
A signed disclosure format is not proof of sandboxing, secret isolation, egress control, teardown, or no retention.
NO MANAGED RUNNERAI execution
Source selection, model identity, purpose, retention, and output provenance need explicit authorization and independently reviewed execution.
NO AI SOURCE SERVICEPublic projection
Making source public must be an affirmative declassification of one exact snapshot—not a storage flag or an indexer's guess.
NO PUBLIC FORGE ENDPOINTHonest limits
Encrypted storage protects a boundary—not every developer endpoint.
A legitimate or compromised client that opens source can retain plaintext, credentials, build output, logs, screenshots, or a complete clone. Repository keys also need their own protected recovery path.
Snapshots are not remotes
A full bundle ceremony does not provide ordinary incremental Git collaboration or a shared authoritative branch head.
Metadata remains
A Gate sees its own opaque identifiers, shard sizes, operation timing, owner/recipient keys required by protocol, and network metadata visible at that endpoint.
Recovery has two parts
The DaemonCloud owner vault and the sealed repository state must both survive. A snapshot or capability alone is not owner recovery.
Deletion is qualified
Deleting known encrypted shards or keys cannot erase source already cloned, exported, cached, logged, or retained by an authorized participant.
Release evidence
Production privacy requires more than a green bundle test.
Live claims still require independent review, real multi-Gate loss and repair, interrupted publication, large and malformed repository tests, clean-device recovery, metadata analysis, release/rollback drills, and operator evidence.
Strongest accurate statement
DaemonGit encrypts a normal Git bundle before DaemonCloud storage, preserves an ordinary Git export path, and can grant a pairwise recipient bounded read access without giving them the storage mutation key. Production collaboration, forge, CI, AI, and public-publication claims remain evidence-gated.
Portable source · explicit authority
Keep Git interoperable.
Move storage without surrendering source.
No fixed price or generally available managed DaemonGit service is offered on this page. Product naming remains subject to clearance.