What is an encrypted git backup?
An encrypted git backup is a complete copy of a git repository that has been cryptographically secured before leaving your local machine. Unlike a plain copy or a cloud sync, it uses authenticated encryption (such as AES-256-GCM) to transform the repository's bundle, including all branches, tags, and history, into ciphertext that only you can decrypt. The encryption key stays on your machine and is never shared with the storage provider. This means even if the cloud account is breached, subpoenaed, or misconfigured, the backup data remains unreadable. An encrypted git backup also typically captures uncommitted work (staged changes, stashed experiments, untracked files) that a normal git push would miss.
Think of it as a safety net for your project. DevSafe takes everything in your project folder, locks it up so only you can open it, and stores it in your own cloud space. If anything happens to your computer, your work is waiting for you, exactly how you left it.
Everything gets encrypted before it leaves your machine. Nobody can read your files except you. Not the cloud company. Not anyone.
An encrypted git backup is a runtime-agnostic encrypted archive of a git object database, designed for agent workspace persistence and disaster recovery. DevSafe creates a git bundle from the repository, encrypts it with AES-256-GCM, and uploads the ciphertext to user-owned S3-compatible storage. The encryption key never leaves the local machine.
Agent workspaces generate state that must survive between runs. DevSafe captures the full git object database plus five namespaces of uncommitted work, encrypts locally, and uploads to any S3-compatible endpoint. Wire it into CI/CD or agent orchestration for automatic state persistence.
The problem
Your code is on your laptop. Maybe you push to GitHub. That covers your committed work, and it covers it well. But think about everything else sitting on your machine right now: the changes you have been working on all morning but have not committed yet, the stashed experiments from last week, the .env files with your API keys, the half-finished rebase you are going to come back to after lunch.
None of that is protected. You are one spilled coffee, one stolen laptop, one SSD failure away from losing hours or days of work. Not the code you finished last month. The code you are writing right now. The freshest work is always the most vulnerable, because it has not been pushed anywhere yet.
Your project lives on one machine. That is a single point of failure. If your laptop breaks, gets stolen, or the drive fails, everything you have been working on disappears.
Pushing to GitHub protects your finished work. But the stuff you are working on right now -- the changes from this morning, the experiments you stashed -- none of that is protected.
Agent workspaces are ephemeral. State loss between runs costs compute and context. Every time an agent session terminates without persisting its working tree, you pay the cost of regenerating that state from scratch.
Context loss is compute waste. Git push covers committed work, but uncommitted changes, staged files, stash entries, and in-progress operations are lost when the workspace shuts down. For multi-agent systems, this means duplicated work across runs.
What you need
Three things. That is it.
- The DevSafe CLI. One binary, no dependencies.
- A cloud storage bucket you own. Cloudflare R2, AWS S3, Backblaze B2, or anything S3-compatible. This is your storage, on your account. DevSafe never touches it except to upload your encrypted backups.
- Five minutes. Seriously.
Three things. That is it. No complicated setup.
One download. Nothing to configure.
Cloudflare R2, AWS S3, or Backblaze B2. Your space, your account.
Seriously. That is all it takes.
Integration requirements for agent and CI environments:
| Component | Requirement | Notes |
|---|---|---|
| DevSafe CLI | Single static binary | No runtime deps. Add to Dockerfile or CI image. |
| S3-compatible storage | Bucket with write access | R2, S3, B2, MinIO. Set via env vars. |
| Encryption key | Generated on first run | Store in CI secrets. Inject at runtime. |
Step 1: Install
One command. DevSafe installs as a single binary with no runtime dependencies. No Docker, no background services, no daemon running while you work.
$ curl -fsSL https://devsafe.com/install | sh
DeVSafe v1.0.0 installed to /usr/local/bin/devsafe
# Verify it works
$ devsafe version
devsafe v1.0.0 (darwin/arm64)That is it for installation. If you prefer Homebrew, brew install hxalabs/tap/devsafe works too. Either way, you should have a working devsafe command in about 10 seconds.
One download. Nothing complicated. DevSafe installs in about 10 seconds.
No Docker. No background services. No complicated setup. DevSafe is a single app that installs with one command. If you have used Homebrew before, you can use that too.
Add DevSafe to your Dockerfile or CI setup step. It is a single static binary with no runtime dependencies.
Add curl -fsSL https://devsafe.com/install | sh to your CI pipeline's setup step or bake it into your base image. The binary is ~15MB and has zero runtime dependencies. Homebrew is also available: brew install hxalabs/tap/devsafe.
Step 2: Connect your storage
DevSafe does not store your backups. You do. Point it at a storage bucket you control, and that is where your encrypted data goes. Nobody else has access unless you give it to them.
$ devsafe init
Storage provider? Cloudflare R2
Bucket name? my-backups
Access key? ********
Secret key? ********
Connected. Bucket is writable.
Encryption key generated and saved to your local keychain.
# Your key never leaves this machine.Your encryption key is generated locally and stays on your machine. It is stored in your system keychain (macOS Keychain, Linux secret service). DevSafe never sends it anywhere. The storage provider never sees it. To restore from a different machine later, transfer this key. DevSafe walks you through that when the time comes.
The important thing here is ownership. The bucket is yours. The credentials are yours. The encryption key is yours. DevSafe is just the tool that connects them. If you stop using DevSafe tomorrow, your encrypted backups are still sitting in your bucket, and you still have the key.
Connect your cloud space. This is where your protected projects will live. You pick the cloud provider, you own the account, nobody else can see your stuff.
Cloudflare R2, AWS S3, or Backblaze B2. Whichever you already use or prefer. DevSafe walks you through the connection step by step.
DevSafe creates a unique key and saves it on your computer. This key never leaves your machine. Not even DevSafe the company can see it. If you ever switch computers, DevSafe will help you transfer it.
Configure the S3-compatible object storage endpoint. All credentials and the encryption key can be injected via environment variables for headless operation.
For CI/CD and agent environments, set these environment variables instead of running the interactive devsafe init:
DEVSAFE_STORAGE_PROVIDER -- r2, s3, b2DEVSAFE_BUCKET -- bucket nameDEVSAFE_ACCESS_KEY -- from CI secretsDEVSAFE_SECRET_KEY -- from CI secretsDEVSAFE_ENCRYPTION_KEY -- from CI secretsKey management note: For agent workspaces, generate the encryption key once and store it in your secrets manager. Inject it as an environment variable at runtime. The key never needs to touch disk in ephemeral environments.
Step 3: Run your first backup
One command. DevSafe finds your git repos, captures everything (including uncommitted work), encrypts it all, and uploads to your bucket.
$ devsafe backup
Discovering repos...
~/Projects/api-server found
~/Projects/mobile-app found
~/Projects/marketing-site found
~/Projects/internal-tools found
Backing up 4 repositories...
api-server
Committed data captured
Uncommitted work captured
Encrypting (AES-256-GCM) done
Uploading done 12.4 MB
Verify pass
mobile-app
Committed data captured
Uncommitted work captured
Encrypting (AES-256-GCM) done
Uploading done 8.7 MB
Verify pass
marketing-site
Committed data captured
Uncommitted work captured
Encrypting (AES-256-GCM) done
Uploading done 3.1 MB
Verify pass
internal-tools
Committed data captured
Uncommitted work captured
Encrypting (AES-256-GCM) done
Uploading done 5.2 MB
Verify pass
Backup complete. 4 repos, 29.4 MB, all verified.
# Time elapsed: 14 secondsThat is the whole thing. Four repos discovered, backed up, encrypted, uploaded, and verified in 14 seconds. You did not have to list which repos to back up. You did not have to configure anything per-repo. DevSafe found them automatically.
This is the moment. One action, and your projects are safe.
DevSafe found all your projects automatically, locked everything up with encryption, and stored it safely in your cloud space. The whole thing took about 14 seconds.
Wire the backup command into your pipeline. DevSafe auto-discovers git repositories in the working directory, captures all state, encrypts, uploads, and verifies.
Add devsafe backup as a post-build or post-test step in your pipeline. It runs non-interactively when environment variables are set. Exit code 0 on success, non-zero on failure.
The backup pipeline: discover repos, create git bundles, capture uncommitted state (5 namespaces), encrypt with AES-256-GCM, upload to S3-compatible storage, verify restorability. Typical run: 4 repos, 29 MB, 14 seconds.
What just happened
Let me break down what DevSafe did in those 14 seconds, because a few of these things are worth understanding.
It found all your git repos automatically. DevSafe is git-aware. It scanned your projects directory and identified every repository without you having to register or configure them individually. New repo tomorrow? It will pick that up on the next backup.
It captured everything, including uncommitted work. Not just your commit history. Your staged changes, your working directory modifications, your untracked files, your stashes. All of it. If your laptop died right now, you would get back exactly what you had, not just what you last committed.
DevSafe never modifies your repos. It does not create commits, move your HEAD, or touch your git history in any way. Your repos look exactly the same before and after a backup. The uncommitted work capture happens as a read-only snapshot, completely separate from your normal git workflow.
It encrypted everything before anything left your machine. Every backup is encrypted with AES-256-GCM before it touches the network. Your storage provider sees encrypted blobs. They cannot read your code, your commit messages, your filenames, or your branch names. Nothing readable ever leaves your machine.
It uploaded to your storage. Not ours. Yours. Your Cloudflare R2 bucket, your AWS S3 bucket, your Backblaze B2 bucket. Whatever you configured in Step 2. There is no DevSafe server in the middle.
It verified the backup is restorable. That "Verify: pass" line at the end of each repo is not cosmetic. DevSafe checks that the uploaded backup is intact and can actually be restored. You do not have to trust that the backup worked. It proves it.
Your keys never left your machine. The encryption key that was generated during devsafe init stayed in your local keychain the entire time. It was used to encrypt your data locally. The encrypted data was uploaded. The key stayed put.
Here is what DevSafe just did for you, step by step:
Automatically discovered all your projects
Grabbed everything, including work you had not saved yet
Locked everything up before it left your machine
Sent to your own cloud space, not ours
Proved each backup can actually be restored
DevSafe never changes your projects. It only reads. Your projects look exactly the same before and after a backup.
Pipeline stage breakdown with approximate performance characteristics:
| Stage | Operation | Notes |
|---|---|---|
| Discovery | Scan for .git directories | Auto-detect, no manifest needed |
| Bundle | git bundle create from object DB | Read-only. Never writes to .git/ |
| State capture | 5 uncommitted namespaces | Index, working tree, untracked, stash, ops |
| Encrypt | AES-256-GCM, per-bundle key | AES-NI accelerated. Streaming for large repos. |
| Upload | S3 PutObject / multipart | Structured key naming for stateless reconstruction |
| Verify | Proof-of-restorability | Non-cosmetic. Validates backup integrity. |
Zero-commit guarantee: DevSafe never creates commits, advances HEAD, or modifies refs. The backup is a read-only snapshot. This makes it safe to run concurrently with active git operations in agent workspaces.
What you can do next
Your repos are backed up. Here is what you might want to do from here.
Restore from any machine
If you set up a new machine (or need to recover after a disaster), install DevSafe, connect to the same storage bucket, provide your encryption key, and restore. DevSafe will discover all the backups in your bucket and let you pick what to bring back.
$ devsafe restore
Available backups:
1. api-server 2 min ago
2. mobile-app 2 min ago
3. marketing-site 2 min ago
4. internal-tools 2 min ago
Restore which? (1-4, or "all"): allNo hunting for keys. No remembering which repos were backed up. DevSafe figures it out from the contents of your bucket.
Check backup health
Want to know the state of all your backups at a glance? One command shows you what is backed up, when, and whether each backup is still healthy.
$ devsafe status
REPO LAST BACKUP STATUS
api-server 5 min ago healthy
mobile-app 5 min ago healthy
marketing-site 5 min ago healthy
internal-tools 5 min ago healthySet up scheduled backups
You probably do not want to remember to run devsafe backup manually every day. Set up a schedule and let it run in the background. DevSafe uses your system's native scheduler (launchd on macOS, systemd on Linux), so it works even when you are not in a terminal.
$ devsafe schedule --every 4h
Scheduled. Backups will run every 4 hours.
# Next backup: 2:00 PMOnce that is running, your code is backed up automatically. Every 4 hours (or whatever interval you pick), DevSafe discovers your repos, captures everything, encrypts, uploads, and verifies. Silently, in the background, without touching your workflow.
I set this up once. I do not think about it anymore. My code is just safe now.
Ready to try it?
DevSafe has a free tier that covers up to 5 repositories. No credit card required. Install it, connect your storage, and run your first backup. The full documentation covers everything from storage setup to advanced configuration.
Sign up for free and get your repos backed up today. It takes 5 minutes.
Your projects are backed up. Here are the two things most people do next.
Get your projects back anytime
If you ever get a new computer or something goes wrong, DevSafe brings everything back. It finds all your backups automatically and lets you pick what to restore.
Set it and forget it
Tell DevSafe how often to back up, and it handles everything in the background. Every few hours, your projects are quietly protected without you lifting a finger. You set it up once and never think about it again.
Ready to try it?
DevSafe has a free tier that covers up to 5 projects. No credit card required. Install it, connect your cloud space, and protect your first project. It takes 5 minutes.
Sign up for free and get your projects protected today.
Production deployment patterns for agent and CI environments.
Restore in fresh workspaces
When spinning up a new agent workspace or CI runner, use devsafe restore to hydrate the workspace from the latest backup. DevSafe discovers all backups from bucket key names alone, requiring no sidecar metadata.
Cron and webhook integration
For persistent environments, use devsafe schedule --every 4h which installs a native system timer (launchd/systemd). For ephemeral environments, trigger backups as a pipeline step or via webhook.
For event-driven backups, call devsafe backup in post-build hooks, deployment scripts, or agent teardown routines. Exit code 0 on success.
Health monitoring
Use devsafe status in monitoring scripts to verify backup recency and health. Parse the output for integration with alerting systems.
Ready to integrate?
DevSafe has a free tier covering up to 5 repositories. No credit card required. Start with a single agent workspace and scale from there. The full documentation covers advanced configuration for multi-agent deployments.
Sign up for free and wire it into your first pipeline.
Frequently asked questions
How long does it take to set up DevSafe for encrypted git backups?
DevSafe can be installed and configured in under 5 minutes. You install a single binary with no dependencies, connect it to an S3-compatible storage bucket you own (such as Cloudflare R2, AWS S3, or Backblaze B2), and run one command. Your first encrypted backup completes in seconds for most repositories.
What does DevSafe encrypt when it backs up a git repository?
DevSafe creates a git bundle from the repository's object database, then encrypts the entire bundle with AES-256-GCM before uploading. This includes all committed history, branches, and tags. It also captures uncommitted work (staged changes, unstaged modifications, untracked files, stash entries, and in-progress operations) in a separate encrypted snapshot. Everything is encrypted locally before it leaves your machine.
Do I need to trust DevSafe with my encryption keys?
No. DevSafe generates and stores encryption keys entirely on your local machine. Keys never leave your device and are never sent to any server. DevSafe uploads only encrypted data to your own storage bucket. Even DevSafe as a company cannot read your backups because the keys exist only on your hardware.
How long does this take to set up?
About 5 minutes from start to finish. You download DevSafe, connect your cloud space, and run your first backup. Most of that time is setting up your cloud storage account if you do not already have one.
Can anyone else see my projects?
No. Everything is encrypted on your computer before it goes anywhere. The cloud provider only sees scrambled data. Even the DevSafe team cannot read your projects. Only you have the key.
What if my computer breaks?
Install DevSafe on your new computer, connect to the same cloud space, and restore. DevSafe finds all your backups and brings them back exactly how you left them. You will need your encryption key, which DevSafe helps you transfer.
How do I rotate encryption keys in CI?
Generate a new key, update your CI secrets, and run the next backup. DevSafe uses per-bundle key derivation, so old backups remain decryptable with the old master key. Store both keys in your secrets manager during the rotation window.
How do I store the encryption key in CI secrets?
Export the key from your local keychain, then store it as a CI secret (GitHub Actions secret, GitLab CI variable, etc.). Inject it as the DEVSAFE_ENCRYPTION_KEY environment variable at runtime. The key never needs to touch disk in ephemeral environments.
Can multiple agents back up to the same bucket?
Yes. DevSafe uses structured key naming ({repo-id}/{type}/{sequence}.enc) that prevents collisions between agents. Each agent can share the same bucket and encryption key, or use separate keys for isolation. Concurrent writes are safe due to conditional write semantics.