Why I Built It 🧠
I did not build SkyeVault because I wanted another backup button. I built it because a serious developer can do everything "right" by normal Git standards and still lose the exact files that mattered: the untracked scratch module, the local worker patch, the root env notes, the generated prompt receipt, the script that has not been committed yet, the one-off migration, the thing sitting in a Codespace while the IDE hops from browser to desktop.
Git is excellent at versioned history after you stage and commit. GitHub is excellent at shared remote history after you push. Neither one is designed to be a sovereign source-custody vault for every local file, every untracked file, every secret-like operator file, and every active workspace artifact before you decide whether it belongs in public source control.
That difference matters. My 0S repo is not a toy repo. It has Workers, Pages projects, brain files, proof receipts, legal surfaces, app lanes, and deployment scripts that evolved through months of real production work. I needed a lane where the repo could be protected as a whole workspace, not only as a sanitized public Git shape.
So the architecture became clear: Git still exists. Git-style vault pushes still exist. Clean client handoffs still exist. But the owner source-custody lane has to be encrypted, receipt-backed, and allowed to carry the whole repo state for recovery. That includes tracked and untracked work. That can include secrets because the vault object is encrypted before storage and unlock-owned by passphrase/control material, not by public Git rules.
What I Mean By "Daemon" ⚙️
A daemon is just a background process. It is not magic, and it is not a cloud ghost living forever after your computer disappears. In this setup, the SkyeVault autosync daemon is a long-running local agent that wakes up on a schedule, scans the repo, packages the source-custody artifact, encrypts it, uploads it to the vault/drive lane, writes receipts, and can send a Resend email with the logo and recovery links when a new successful stream lands.
The current cadence is roughly ten minutes. That means the agent is designed so your worst normal loss window is the work created after the last completed artifact. If the daemon finishes at 12:00 and your workspace dies at 12:07, the 12:00 artifact is the clean recovery point. If a scan is actively streaming when the machine dies, you recover from the last completed receipt, not from a half-written object.
This is why I keep using the word "receipt." A backup you cannot prove is a hope. A vault upload with a digest, byte count, timestamp, artifact receipt, control-pack receipt, and notification trail is evidence. I want the system to show what it captured, when it captured it, and how to get back to it.
VS Code Closing Is Not The Same As Workspace Death 🖥️
This part matters because developers use the word "workspace" loosely. Closing the VS Code window usually means the editor UI is gone. It does not automatically mean the machine, Codespace, VM, dev container, or file system disappeared. If the underlying workspace is still alive, the daemon can keep running and keep scanning.
But if the actual workspace stops, gets deleted, loses disk, or the container is killed before the daemon has completed its next artifact, no local process can keep reading files from a file system that is no longer there. That is not weakness in the vault architecture. That is physics in software clothing.
The point of the autosync lane is to keep narrowing the blast radius. It turns "I lost half my repo" into "I should have a recent encrypted receipt." It turns "I forgot to commit" into "the vault captured the uncommitted source state if the daemon finished." It turns IDE switching from browser Codespaces to local VS Code into a workflow with a background source-custody net under it.
My practical rule
If I am about to do a major risky move, I can still force a manual SkyeVault push. The daemon is the always-on habit. Manual push is the deliberate checkpoint. Git commit is the public or team history move. These lanes are related, but they do not replace each other.
Why It Is Not GitHub, And Why That Matters 🔐
Public Git hygiene says do not push secrets. That rule still matters for GitHub, GitLab, public remotes, open-source repos, and client source deliveries. But my owner vault is not a public Git remote. It is an encrypted source-custody wrapper. The design goal is different: recover the workspace as it actually existed, including the private operator files that should never be exposed in a public repo.
That is why SkyeVault keeps multiple push modes. A sanitized Git-shaped handoff is useful when I need to share a clean repo. A Git bundle lane is useful when I want Git parity. A full source-custody lane is useful when I never want to lose the active repo state again. The protected vault can carry things that public Git should not carry because the vault object is encrypted and owner-unlocked.
Archive format is not the security boundary. A zip, a tar, or a tar compressed with zstd are containers. The security boundary is the encrypted wrapper and the unlock model. The reason I currently prefer the tar/zstd lane for full source custody is speed, streaming behavior, and large-repo handling. The reason people love zip is convenience. The architecture can expose easy restore/download surfaces while still using the faster archive format under the hood.
In plain language: the vault should feel easy to a human, but the transport should be strong enough for the repo. I do not need the storage layer to understand my files. I need it to hold encrypted source custody with receipts.
The Revision Rounds Were The Point 🛠️
This did not start as one perfect script. It became stronger through pressure. Every time the 0S exposed a weak assumption, I tightened the lane.
The early lane focused on repo-like pushes, Git bundles, clone/fetch/push patterns, and developer-friendly recovery thinking.
Then came clean delivery paths for client or public movement, where secrets and private operator material stay out of the shared source lane.
The owner lane became explicit: tracked, untracked, local-only, and secret-like material belong in the encrypted vault artifact when the purpose is recovery.
The upload path moved toward faster direct streaming, better large-artifact behavior, and receipts that show the vault actually received the object.
The repo now has a background agent, proof publishing, Resend owner alerts, dashboard enable/disable controls, and links back to unlock/vault/proof surfaces.
The marketing and legal surfaces now explain the no-guarantee boundary without hiding the proof: the founder's own 0S repo is the stress test and live demonstration.
That is how real infrastructure grows. Not by pretending failure never happens. By noticing the failure mode, reducing the recovery window, adding receipts, making the next recovery easier, and refusing to let "that was local only" be the reason source disappears.
The Boundary: No Perfect-Tech Promise 🚧
Despite the stress testing, live owner usage, encrypted source-custody mode, proof receipts, and ten-minute daemon posture, this is not a guarantee that no data can ever be lost. It is an infrastructure answer built to reduce loss, prove what was captured, and make recovery real.
If the workspace dies before the first successful artifact, there is nothing for the vault to restore. If the machine stops while a new stream is in progress, the restore target is the last completed receipt. If a user disables notifications, the upload can still work, but they will not receive every email. If the passphrase/control material is lost, encryption did its job and recovery becomes a custody problem, not a storage problem.
That honesty is part of the product. I would rather say the real boundary out loud than sell fake certainty. The claim is not "nothing can ever go wrong." The claim is: when ShYT happens, SkyeVault is built so the last clean move has a better chance of still existing, still being provable, and still being recoverable.
Proof Surfaces And Recovery Links 🧾
The live 0S proof endpoints stay gate-owned because source-custody proof can point at private operational metadata. Public readers get the architecture story, the install prompt, and the vault lane links. Owners and operators use the shared FS27/SkyGate/Free99 credential lane to see the gated proof details.