Thinking out loud · where does .git live & how does it stay one truth
Get .git off EFS.
Then the hard part begins.
A single reasoning chain, drawn as a map. It starts with a small, concrete move — put .git on the sandbox's own SSD, make that storage persistent, back it up on a schedule. That fixes real pain. But the moment there is more than one sandbox, keeping two git trees in sync is too complex to be worth it — so the model collapses to one server per team. That collapse buys simplicity and hands back two new problems: blast radius and burst load. This page follows that thread end to end.
The whole argument in one line
Move git to local SSD, refuse to sync two trees, and you're forced into one server per team — which is simpler everywhere except security and scale.
Everything below is that sentence, expanded and pinned to its trade-offs. sandbox = the machine a team's work runs on; .git = the repo's history and index, the thing git touches on every command.
01
The mental map
Read it top to bottom. Each step is forced by the one above it — the design isn't a menu of options, it's a chain where every link pulls the next.
1The requirement
Bring .git onto the sandbox's SSD — persistent, with regular backup
Stop treating the repo as a file on a shared network drive. It lives on local solid-state storage attached to the sandbox, that storage survives restarts, and a scheduled backup makes it recoverable.
because it fixes
2What it buys — two wins
Fast git, and durability
The whole reason to move: get git off the network filesystem, and get a real safety net under the data.
Win 1 · speed
No more git on the EFS layer
Every status, add, commit hits local SSD, where git is designed to run — milliseconds, not seconds.
Win 2 · durability
Persistent + backed up
The disk outlives the process; the backup outlives the disk. Losing a sandbox stops meaning losing work.
but it raises
3The snag
Git across two sandboxes is too complex to sync
Once the repo lives on a box's own disk, a second box means a second copy. Keeping two independent git trees in agreement — branches, index, refs, in-flight work — is exactly the sync tax we were trying to escape, now harder because it's two live filesystems, not one shared one.
so instead
4The move
Don't sync — keep the whole directory on one server per team
Sidestep the problem entirely. At any point in time a team has exactly one server holding the whole working directory. No second tree, so nothing to reconcile. Recovery and onboarding both flow from that one place.
If it dies
Restore from backup
The scheduled backup is the recovery path — stand a fresh server up from it.
If someone joins
Served from here
A new teammate gets the existing server's state — no fresh clone, no divergence.
which leaves two problems
5The two open problems
One box per team is simple — and concentrated
Collapsing to one server removes sync but concentrates everything onto one machine. That concentration is exactly where the two risks live.
Problem A · security
Blast radius = the whole team
One shared server means the trust and failure boundary is team-wide — one compromise reaches everyone's work.
Problem B · scale
A burst of 100s of drafts
Suddenly hundreds of drafts spin up at once and a single sandbox can't absorb the load.
02
Why the first move is worth making
Before the complications, the base decision stands on its own. Putting .git on local SSD with backup is a net win regardless of what comes after — it removes a source of slowness and a source of data loss in one stroke.
Win 1 · performance
Git stops paying the network tax
On network storage, a single git status can stall for seconds because every object read crosses the wire. On the sandbox's own SSD, git runs where it was built to run. This is the immediate, felt improvement.
Win 2 · durability
Persistent storage + scheduled backup
Local disk alone would trade the network problem for a fragility problem. Persistence keeps the repo across restarts; the regular backup keeps it across the loss of the machine itself. Together they make "the box died" a recoverable event, not a catastrophe.
03
The snag that forces the design
The base move is clean until you ask a simple question: what happens with a second sandbox? That question is the fork in the road — and it rules one path out.
⚠ The blocker
Two sandboxes means two independent git trees on two local disks. Reconciling them — branches, staged changes, refs, work that's mid-flight on both — is a distributed-state problem, and it's harder than the shared-filesystem sync we started with. The honest conclusion: don't sync two trees at all. Keep the whole directory in one place.
04
The move: one server per team
If syncing is off the table, the directory has to be singular. At any moment, one team maps to one server that holds everything. Death is handled by the backup; growth is handled by serving newcomers from that same server.
A team
Many people, many drafts
- N members
- M drafts in flight
- one shared codebase
- one shared history
One server · at any point in time
The team's server
- the whole directory, on local SSD
- .git lives here, natively
- persistent storage
- scheduled backup off-box
- no second tree to sync
If it dies
Restore from backup. A new server is stood up from the latest snapshot. Recovery time and data-loss window are set by the backup cadence.
If a user joins
Served from here. New members attach to the existing server and its state — no fresh clone, no divergent copy to reconcile later.
05
The two problems it hands back
One server per team is simple to reason about — and that simplicity comes from concentration. Everything a team has now sits on one machine, which is precisely what makes these two risks sharp. Neither is solved yet; both are the real work ahead.
Problem A · security
Blast radius reaches the whole team
With one shared server, the trust boundary and the failure boundary are both team-sized. A single compromise — or a single buggy draft with too much reach — can touch everyone's work at once, not just the person who caused it.
How do we isolate one member's, or one draft's, blast radius inside a machine they all share? Per-draft sandboxing, permission scoping, or splitting the box are the candidates.
Problem B · scale
A sudden burst of hundreds of drafts
The load isn't steady. Hundreds of drafts can be created at once, and a single sandbox can't absorb that spike — CPU, memory, disk and process count all hit a wall on one box.
Does one server per team hold under burst, or does a draft need to be able to spill onto more capacity — reintroducing the very multi-box problem we avoided in §03?
The crux
The chain is airtight until the last link: local SSD → durability → no two-tree sync → one server per team each follows from the one before. But "one server per team" is a bet against concentration — it wins on simplicity only if we can also answer blast radius and burst load. Those two are the price of the whole design, and they're still unpaid.