What is DevSafe?
DevSafe is the first local-first encrypted git backup tool with user-owned storage. It solves a gap that has existed since cloud sync services became popular: no commercial product offered developers encrypted, git-aware backups that store data in the developer's own cloud account. DevSafe discovers git repositories on your machine automatically, creates git bundles from the internal object database (bypassing the filesystem to avoid cloud sync corruption), encrypts everything with AES-256-GCM before any network transfer, uploads to your S3-compatible storage bucket, and verifies that each backup is actually restorable. It also captures uncommitted work across five namespaces without creating commits or modifying your repository.
DevSafe protects your projects automatically. It finds every project on your machine, creates an encrypted backup, and stores it in your own cloud storage. No one else can read your backups. Not even us.
You know that feeling when you have been building something for hours and you realize you have not saved anything anywhere safe? DevSafe fixes that. It runs quietly in the background, finds your projects, encrypts everything, and puts a backup in a place only you control.
It even saves work you have not committed yet. That half-finished feature, those files you just created, that thing you were about to push but did not. DevSafe grabs all of it without touching your project.
DevSafe is a local-first encrypted git backup tool designed for environments where agents generate and modify code across multiple repositories. It reads from git's internal object database (not the filesystem), produces AES-256-GCM encrypted bundles, uploads to user-owned S3-compatible storage, and verifies restorability at creation time. It captures five namespaces of uncommitted state without creating commits or modifying refs.
Agent-driven development creates a specific backup gap. Agents generate high volumes of code changes across multiple repositories in short time windows. Traditional backup tools cannot distinguish between pushed commits (already protected by the remote) and the uncommitted agent output that exists only on the local machine. DevSafe captures that uncommitted layer without interfering with the agent's working state.
Why DevSafe exists
There are somewhere between 75 and 100 million developers in the world. They write code every day, store it in git repositories, and depend on that code for their livelihoods. We searched for a commercial product that offers local-first, encrypted git backup with user-owned storage. We found zero.
That is not an exaggeration. The tools that exist fall into three categories, and all three have the same problem. Cloud sync services like iCloud, Dropbox, and OneDrive will happily sync your project folders, but they corrupt .git directories through file locking conflicts, partial writes, and race conditions. Git's own documentation warns against this. GitHub and GitLab back up your pushed commits, but they cannot protect uncommitted work, and they hold the keys to your private repositories. Traditional backup tools like Time Machine capture everything on your disk, but they do not understand git, they do not encrypt before upload, and they do not verify that what they captured is actually restorable.
We built DevSafe because this gap should not exist. Developers deserve a backup tool that understands git from the inside, encrypts everything before it leaves the machine, stores data in the developer's own cloud storage, and proves the backup works. That is what v1.0 does.
iCloud, Dropbox, and OneDrive silently break projects. They try to sync your project files and corrupt the version history in the process. This is a documented problem. It has destroyed people's work.
Here is the problem. You build something amazing. Maybe you are 70% of the way through a project and it is coming together. Your files are sitting in an iCloud or Dropbox folder because that felt like the safe choice. Then one day you open the project and something is broken. Not your code. The project itself. The history is corrupted. Sync conflicts mangled the internal files that track your changes.
GitHub only protects what you already pushed. The work you lose in a crash is always the most recent work. The stuff you have not pushed yet. That is what DevSafe protects.
We looked for a tool that solves this. Something that actually understands projects, encrypts your work before sending it anywhere, and stores backups in a place only you control. We could not find one. So we built it.
We surveyed commercial backup tools across three categories. Cloud sync (iCloud, Dropbox, OneDrive) corrupts git internal structures through file-level locking conflicts and partial writes. Remote hosting (GitHub, GitLab) protects pushed commits but not uncommitted state, and the hosting provider holds keys to private repositories. System backup (Time Machine, Backblaze) captures raw bytes without understanding git's object model, producing backups that may be structurally invalid.
Zero products in the market offer the combination of: git-aware backup (reads from the object database, not the filesystem), pre-upload encryption with user-held keys, user-owned storage (no vendor-controlled backend), and verified restorability. DevSafe was built to fill that exact gap. This is not a wrapper around existing tools. The backup pipeline reads git plumbing directly.
What v1.0 includes
Encrypted git backup
Every backup is encrypted with AES-256-GCM before it leaves your machine. Your encryption keys never leave your machine. Not to us, not to your storage provider, not to anyone. The storage provider sees encrypted blobs. They cannot tell whether the blob contains a weekend project or production infrastructure. That is the point.
Auto-discovery
DevSafe finds every git repository on your machine automatically. You do not configure each repo one at a time. You do not maintain a list. You run it, it scans, and it knows what needs to be backed up. If you create a new repo tomorrow, DevSafe finds it on the next run.
User-owned storage
Your backups go to your S3-compatible storage bucket. Your account, your credentials, your data. We never see it, never touch it, never have access to it. If you stop using DevSafe tomorrow, your backups are still sitting in your bucket, encrypted with your key. No vendor lock-in. No data hostage.
DevSafe works with any S3-compatible storage provider. Cloudflare R2, AWS S3, MinIO, Backblaze B2. You pick the provider. You own the bucket. We just encrypt and upload.
Uncommitted work capture
This is the feature that made us build DevSafe in the first place. Every other backup tool protects what you have already committed. DevSafe protects what you have not committed yet.
Your staged changes. Your working tree modifications. Files you created but have not added to git. Stashed work from three days ago. Even in-progress operations like a half-finished rebase. DevSafe captures all of it without creating commits, without modifying your refs, without touching your repository's state. A snapshot of everything, with no side effects.
The work you lose in a crash is always the work you have not committed. That is the most recent work. The freshest thinking. The hardest to reconstruct. DevSafe captures it before that happens.
Verified restore
Most backup tools tell you the upload succeeded. DevSafe tells you the backup is restorable. There is a difference. An upload can succeed and still produce a corrupt backup. A file can arrive intact but be structurally invalid. DevSafe verifies that each backup can actually be restored at the time it is created, not weeks later when you need it. Cryptographic proof, not a progress bar that says "done."
Military-grade encryption, zero effort. Every backup is scrambled before it leaves your computer. Nobody can read it. Not the storage company, not hackers, not even us. Your projects stay private.
Finds all your projects automatically. You do not need to add projects one by one. DevSafe scans your machine and finds every project. Start a new one tomorrow and it will be picked up on the next backup.
Your storage, your data, your control. Backups go to a storage bucket that you own. If you stop using DevSafe, your backups are still there. No one can hold your data hostage.
Saves work you have not committed yet. That half-finished feature you have been working on for the last two hours? The files you just created? DevSafe grabs all of it. This is the work most at risk during a crash, and DevSafe catches it without you doing anything.
Every backup is verified as restorable. Other tools tell you the upload finished. DevSafe proves the backup actually works. There is a difference between "uploaded" and "restorable." DevSafe checks both.
AES-256-GCM with HKDF-SHA256 key derivation. Two-level key hierarchy: master key to per-repo key to per-bundle key. 96-bit random nonces per NIST SP 800-38D. Keys never leave the local machine. The storage provider sees opaque encrypted blobs with no metadata leakage about repository contents or structure.
Filesystem scan locates all git repositories on the machine. No configuration per repository. New repositories are picked up on the next run. This is relevant for agent workflows where new repositories are created programmatically. The discovery engine handles standard repos, bare repos, and worktree setups.
Uncommitted state capture covers five namespaces: git index (staged changes), working tree modifications, untracked files, stash entries, and in-progress operations (rebase, merge, cherry-pick). Capture is atomic and zero-commit. No refs are modified, no commits are created, no reflog entries are added. This is the critical capability for agent workspaces where code changes accumulate between pushes.
Backup verification happens at creation time, not at restore time. Each backup is proven restorable before the upload is considered complete. This is cryptographic proof, not a status code check. For CI/CD pipelines, this means backup operations either succeed verifiably or fail loudly. No silent corruption.
User-owned S3-compatible storage. Supports Cloudflare R2, AWS S3, MinIO, Backblaze B2. Structured key naming enables stateless reconstruction from cloud metadata alone. No sidecar database, no vendor-controlled backend. If the tool is removed, backups remain in the user's bucket, encrypted with the user's key.
Free tools, no account required
Alongside the backup product, v1.0 ships four free command-line tools. No account required. No email required. Install and run.
- devsafe scan finds git repositories sitting inside cloud sync folders (iCloud Drive, Dropbox, OneDrive, Google Drive). These repos are at risk of corruption. It reports which ones are in danger.
- devsafe diagnose finds secrets in your repositories that AI coding tools can read. API keys, tokens, credentials in config files. If an AI assistant can see your codebase, it can see those secrets.
- devsafe health scores each repository across multiple risk factors: large untracked files, missing
.gitignorerules, stale branches, secrets exposure. One score, one report, per repo. - devsafe mcp-scan audits every MCP config on your machine for hardcoded secrets: API keys in Claude Desktop, Cursor, VS Code, and Cline configs. It shows you how to fix each one.
These tools exist because we believe every developer should be able to assess their risk for free, whether or not they use DevSafe for backups.
DevSafe ships four free tools alongside the backup product. No account needed. No email. Just install and run them.
Sync Folder Scanner checks if any of your projects are sitting inside iCloud, Dropbox, or OneDrive folders. If they are, they are at risk of silent corruption. This tool finds them and warns you.
Secrets Scanner finds API keys and passwords hiding in your project files. If you use an AI coding assistant, it can see those secrets too. This tool finds them before someone else does.
Project Health Check gives each of your projects a health score. Are there large files that should not be tracked? Missing safety rules? Old branches piling up? One report tells you everything.
MCP Config Auditor checks your AI tool configurations (Claude Desktop, Cursor, VS Code, Cline) for hardcoded API keys. Finds them and shows you how to fix each one.
These tools are free because everyone should be able to check if their work is at risk, whether or not they use DevSafe for backups.
Four standalone CLI tools ship free with no account required. These are relevant for agent infrastructure auditing:
devsafe scan: Detects git repositories inside cloud sync folders (iCloud, Dropbox, OneDrive, Google Drive). Useful for identifying repos at risk of filesystem-level corruption from sync conflicts.
devsafe diagnose: Scans repositories for exposed secrets (API keys, tokens, credentials). Critical for agent workspaces where AI coding tools have read access to the entire repository, including config files with hardcoded credentials.
devsafe health: Per-repository health scoring across multiple risk dimensions: large untracked files, missing gitignore rules, stale branches, secrets exposure. Can be integrated into CI checks.
devsafe mcp-scan: Audits MCP server configurations across Claude Desktop, Cursor, VS Code, and Cline for hardcoded secrets. This is the first tool specifically designed to audit the configuration surface area that MCP introduced.
What we did not build (and why)
We did not build another cloud backup service. Cloud backup means the vendor holds your data and your keys. That is not backup. That is trust with extra steps.
We did not build a GitHub backup tool that only covers pushed code. Your last push is already on GitHub. The risk is everything between pushes. The uncommitted work, the staged changes, the files you have not added to git yet. A tool that only backs up pushed code protects what is already protected.
We did not build a wrapper around rsync or a file-copy tool that treats .git like any other directory. Git repositories have internal structure. Pack files, indexes, refs, loose objects. A file-level copy can produce something that looks like a repo but does not function as one. DevSafe is git-aware. It reads from git's internal structures and produces backups that are structurally valid, not just byte-identical.
We built a tool that understands git from the inside. That is the difference between a backup that copies files and a backup that actually works.
We did not build another cloud backup where someone else holds your stuff. If the backup company has your data and your keys, that is not a backup. That is trusting a stranger with your work.
We did not build a tool that only protects what you already pushed to GitHub. GitHub already has that. The real risk is the work sitting on your machine that you have not pushed yet. That is what disappears in a crash.
We also did not build a simple file copier. Projects have a complex internal structure that regular copy tools do not understand. Copying all the files can produce something that looks right but is actually broken inside. DevSafe understands how projects actually work and creates backups that are guaranteed to be valid.
DevSafe understands your projects from the inside. That is the difference between a backup that copies files and a backup that actually works when you need it.
Three common approaches were evaluated and rejected:
Vendor-controlled cloud backup. The vendor holds data and encryption keys. This fails the zero-trust requirement. For agent infrastructure, it means a third party has access to every repository the agent touches, including credentials, proprietary logic, and unreleased code.
Remote-only backup (GitHub/GitLab mirroring). Protects pushed commits only. Agents frequently accumulate significant uncommitted state between pushes. A mirror of the remote protects what is already protected and misses the high-value local delta.
Filesystem-level copy (rsync, tar, Time Machine). Treats git internals as flat files. Pack files, index structures, and refs have internal consistency requirements. A byte-level copy can produce a structurally invalid repository that appears intact until a restore is attempted. DevSafe reads from git's object database directly, producing bundles that are verified as structurally valid.
The free tier
The free tier is not a trial. It does not expire. It includes:
- 5 repositories
- 500 MB of backup storage
- AES-256-GCM encryption
- Auto-discovery
- Free restore, always
No credit card. No time limit. The encryption is the same as the paid tiers. The restore is the same as the paid tiers. We do not gate security behind a paywall.
Restore is always free on every tier. Charging for restore creates an incentive not to test your backups. We want you to restore early and often. So we never charge for it.
The free tier is not a trial. It does not expire. You get:
5 projects, 500 MB of backup storage, full encryption, auto-discovery, and free restore. No credit card. No time limit. The encryption is identical to the paid plans. We do not make your backups less secure because you are on the free tier.
Restoring your work is always free. On every plan. Forever. Some backup tools charge you to get your own data back. We think that is wrong. We want you to test your backups often, so we never charge for it.
The free tier is permanent, not a trial. 5 repositories, 500 MB backup storage, full AES-256-GCM encryption, auto-discovery, and unlimited free restores. No credit card required. Encryption and restore behavior are identical across all tiers. Security is not gated behind payment.
Restore is free on every tier. Charging for restore creates a perverse incentive: users avoid testing backups to save money, then discover corruption at the worst possible time. Free restore means the verification loop stays tight. For agent infrastructure, this means automated restore-and-verify workflows incur no marginal cost.
What comes next
We are building in public. The roadmap is on our site. We would rather ship 8 features that work perfectly than 50 features that work mostly. Every feature that ships will meet the same standard as v1.0: encrypted, verified, user-owned, git-aware.
We read every piece of feedback. If something is broken, we want to know. If something is missing, we want to hear about it. The product gets better when developers tell us what they actually need, not what we assume they need.
We are building in the open. The roadmap is on our site so you can see what is coming. We would rather ship a small number of features that work perfectly than a long list of features that break when you need them.
We read every piece of feedback. If something is broken, tell us. If something is missing, tell us. The product gets better when people tell us what they actually need instead of us guessing.
The public roadmap is available. Development follows a deliberate constraint: every shipped feature must be encrypted, verified, user-owned, and git-aware. No feature ships without meeting all four criteria. Upcoming work includes deeper integration surfaces for CI/CD pipelines and agent orchestration tools. Feedback channels are open for capability requests and bug reports.
Get started
DevSafe v1.0 is available now.
- Sign up for free and back up your first 5 repos in minutes.
- Read the docs for setup guides, architecture details, and API reference.
- Join the Discord to ask questions, report issues, or just say hello.
We built DevSafe because it needed to exist. We hope it protects your work the way it protects ours.
DevSafe v1.0 is ready. Here is how to get going:
Sign up for free and protect your first 5 projects in minutes. No credit card needed.
Read the guides for step-by-step setup instructions.
Join the Discord to ask questions, get help, or share what you are building.
We built DevSafe because your work deserves real protection. We hope it keeps your projects safe the way it keeps ours safe.
DevSafe v1.0 is available now. Entry points:
Free tier: 5 repos, 500 MB, full encryption. No credit card. Suitable for evaluating the backup pipeline against your agent workspace setup.
Documentation: Setup guides, architecture details, and API reference. Covers storage provider configuration, key management, and CLI usage for scripted/automated workflows.
Frequently asked questions
What is DevSafe and how does it protect source code?
DevSafe is a local-first encrypted git backup tool. It discovers every git repository on your machine, creates git bundles from the internal object database, encrypts them with AES-256-GCM before they leave your machine, and uploads them to your own S3-compatible cloud storage. Your encryption keys never leave your machine, so neither DevSafe nor your storage provider can read your backups. It also captures uncommitted work including staged changes, working tree modifications, untracked files, and stashes without modifying your repository.
Does DevSafe require its own server or cloud account?
No. DevSafe stores backups in your own S3-compatible storage bucket (your account, your credentials, your data). It works with Cloudflare R2, AWS S3, MinIO, Backblaze B2, and any other S3-compatible provider. DevSafe never sees, touches, or has access to your backups. If you stop using DevSafe, your backups remain in your bucket, encrypted with your key. There is no vendor lock-in and no data hostage scenario.
Can DevSafe back up uncommitted git changes?
Yes. DevSafe captures five namespaces of uncommitted work: staged changes (the git index), working tree modifications, untracked files not yet added to git, stashed work, and in-progress operations like a half-finished rebase. It does this without creating commits, without modifying refs, and without touching your repository state. This is the data most at risk during a crash or disk failure because it exists only on your local machine.
What does DevSafe actually do?
DevSafe finds all the projects on your computer, creates encrypted backups, and stores them in a cloud storage account that you own. Nobody else can read your backups. It also saves work you have not committed yet, which is the stuff most likely to be lost in a crash.
Do I need to set up a server or special account?
No server needed. You connect your own cloud storage (like Cloudflare R2 or AWS S3) and DevSafe sends encrypted backups there. If you ever stop using DevSafe, your backups stay in your account. Nothing is locked away.
Can it save work I have not pushed to GitHub yet?
Yes. That is one of the main reasons DevSafe exists. It captures everything on your machine that is not on GitHub yet: files you changed, files you just created, things you stashed, even half-finished work. It does this without messing with your project at all.
What is DevSafe's architecture?
Local-first CLI that reads from git's object database via plumbing commands (not the filesystem), produces git bundles, encrypts with AES-256-GCM using a two-level HKDF-SHA256 key hierarchy, uploads to user-owned S3-compatible storage, and verifies restorability at creation time. Stateless reconstruction from cloud key names alone. No sidecar database.
Does it require a DevSafe-managed backend?
No. User-owned S3-compatible storage is the only backend. DevSafe never holds data, keys, or metadata. The tool is entirely local-first. Compatible providers include Cloudflare R2, AWS S3, MinIO, and Backblaze B2. No vendor lock-in by design.
How does uncommitted state capture work with agent workflows?
Five-namespace atomic capture: git index, working tree, untracked files, stash, and in-progress operations. Zero-commit, zero-ref-modification. No reflog pollution. This is critical for agent workspaces where significant code changes accumulate between pushes. The capture operation is non-destructive and does not interfere with the agent's working state.