Technology · History

We don't do snapshots.
We remember everything.

Chunks are immutable — nothing ever overwrites them. Every change to your filespace is recorded the instant it happens, with nanosecond granularity. The filespace never forgets, so "taking snapshots" stops being a chore and starts being a fact.

The old way

Snapshot schedules always lose.

A snapshot is a bet that nothing important happens between now and the next one. Studios lose that bet on the worst possible day.

Up to 59 lost minutesHourly snapshots sound safe until the crash lands at :59. Everything since the last save — the take, the comp, the mix — gone.

Tuned after the disasterEvery snapshot schedule in the world was tightened the day after it wasn't tight enough. The schedule is always calibrated to the previous catastrophe.

A quota on your pastKeep 24 hourlies, 30 dailies, 12 monthlies… history pruned to fit a budget. The version you need is always the one that aged out.

Stone has no schedule because Stone has no snapshots. Every mutation is kept, timestamped to the nanosecond. The timeline itself is the storage.

Time travel

Rewind anything to any instant.

A file, a folder, the whole project — pick a moment and go there. Not "the nearest backup". The exact moment: the second before the bad merge, the nanosecond before the overwrite.

Here's the quiet trick: because chunks are immutable and deduplicated, a rewind is just a new recipe pointing at old chunks. Nothing is copied. Nothing re-uploads. The past was never moved out of the bedrock — Stone simply points at it again.

Which means restoring a terabyte takes about as long as renaming it.

terminal

$ stone rewind ~/Stone/Project_Aurora --to "2026-07-14 14:03:07"
✓ 1,284 files restored to that instant
   0 bytes re-uploaded — the chunks never left

Immutability

Ransomware can't rewrite the past.

When ransomware encrypts your files, it believes it's destroying them. On Stone, it's merely writing new chunks. The originals are immutable — still exactly where they were, one rewind away.

An attack is just a bad edit

To the filespace, mass encryption looks like any other burst of writes: new chunks, new recipes, old ones untouched. Rewind the tree to the minute before the attack and carry on. The ransom note is the only file worth deleting.

Deleted ≠ destroyed

Deleting a file removes it from view, not from history. Nothing is truly destroyed until your retention window says so — and until then, every "oh no" has an undo.

Versioning

Versions that cost almost nothing.

A version is a recipe. A recipe is a tiny list of fingerprints — kilobytes, no matter how heavy the file it describes.

Two versions of an 86 GB master share almost all of their chunks; what's actually new is the delta and a sliver of bookkeeping. So Stone doesn't ask you to be disciplined about what to keep.

Keep every export. Every bounce. Every draft. Every final_final_v3 that turned out not to be final. Deduplication makes the chunks cheap; recipes make the versions nearly weightless. Your history grows like a ledger, not like a landfill.

Retention

Retention, your call.

Every plan records everything. The plans differ in how far back you can rewind.

Solo

30 days

A month of every keystroke's consequences, fully rewindable.

Studio

180 days

Long enough to survive a client who changes their mind in Q3 about Q1.

Business

1 year

A full production cycle of history, down to the nanosecond.

Enterprise

Unlimited

The filespace never forgets. Neither do your auditors — good news for both.

History rides Stone's storage tiers — hot, standard, archive, and a long-term tier built for compliance archives that must outlive the project. Compare plans →

Who can rewind, and how far, is governed by the same permissions as everything else. Permissions & sharing →

We don't do snapshots.We remember everything.