When your assistant deploys a site to juudd, the files are stored under a new version and never written again. There is no "current" marker that gets moved to the new version. The newest version is found by listing the versions and taking the last, and rolling back is publishing an older one with publish_deploy.
That is the decision. The rest of this post is the test that forced it, the pointer we decided not to have, and the collision that made the version name what it is.
One question decides the format
The test for any storage decision here is a single question: can a script that holds only the store's own credentials list every site, pick each one's newest version, and rebuild it? If answering needs a database, the decision is wrong.
The reason is the failure we plan for. A recovery that has to ask a database what to rebuild depends on that database being reachable and current on the worst day, which is the day it is least likely to be. So the store of deploys is the source of truth for what exists, and everything else is derived from it.
The pointer we did not build
The obvious design keeps a mutable object next to the versions that says which one is current. We did not build it, for two reasons.
It would be the one deploy object that gets overwritten, among versions whose whole rule is that nothing is rewritten. And it would be the overwritten object whose history matters most, because it is the one that says which deploy was live.
A pointer can disagree with what is stored; a listing cannot. Recovery has to list the versions to find the files anyway. Taking the last one costs nothing and removes a whole class of failure where the marker says one thing and the store holds another.
Rollback follows for free. Every earlier version is still there, addressable by name, and publishing it is the same code path as publishing a fresh deploy. publish_deploy takes an optional version, and with none it publishes the newest stored one.
The version name does the work
A version is a UTC timestamp, to the millisecond, then a dash, then eight characters of a hash of the files, shaped like 20261029T031500123Z-9f3a1c7e (an illustration, not a real version). It sorts alphabetically into time order, which is the property that lets "newest" be the last name in a listing.
The milliseconds are not decoration. The first version of this had timestamps to the second. Two deploys that landed in the same second tied on the timestamp and fell through to the hash, and a hash is not chronological, so "newest" could name the older of the two and a rollback could quietly become a roll-forward. The first end-to-end run through the tools produced exactly that collision, and it only came out in the right order by luck.
Two deploys inside one millisecond still tie-break on the hash. At that point they are simultaneous by anything we can observe, and both are stored and addressable regardless. The hash also means an identical redeploy gets a visibly identical suffix.
A manifest says what a version is
Each version carries one manifest listing every file and function with its path, size, content type and a SHA-256 of its bytes, plus the site, the version name, the creation time and the hostname. The hostname is in there on purpose: it is the one fact a rebuild cannot recompute once the host that served it is gone.
The manifest is written last. Until it lands the version is incomplete, and its absence is how a half-written version is recognised instead of trusted. The manifest has a schema field from its first write, so a later change to its shape is a migration and not a guess about which shape an old object is in.
Store first, publish second
A deploy is two calls, in a fixed order. Storing happens first, and publishing reads the stored version back rather than accepting files from the caller. That makes what visitors get the same thing that can be recovered, and it makes a recovery onto a different host the same function with a different target.
The order is mandatory. A deploy that was published but never stored is the one case this format exists to prevent.
What we left alone
Files are stored per version, not shared between versions. Content addressing would save space by sharing identical files. We store each version's files under its own name anyway, because recovery then needs one listing per site and no indirection. The manifest still records a hash per file, so a sharing layer remains possible without changing the format. Storage is not the scarce resource here; being understandable under pressure is.
Which version visitors see is a separate question from which is newest. This post is about how stored versions are named and found. It does not claim the newest version is always the one being served, and a rollback is exactly the case where it is not.
The rule, once
Never keep a pointer you can derive: juudd stores every deploy once under a name that sorts by time, finds the newest by listing, and makes a rollback a publish of an older version. The tools and their limits are listed in the docs.