libuv.rlib
\nWaiting
\nuv
\nWaiting
\nuv.d
\nWaiting
\nWriting outputs
\nWe’re rewriting Nix in Rust, and it needs to be split into layers and modernized.
\nIts storage, build machinery, and higher-level tools can each be useful on their own.
\nYou should be able to use one layer without adopting the whole stack.
\nThat matters even more in agentic development. Agents produce more source code, more versions of it, and more build artifacts as they explore and test changes.
\nKeeping every copy quickly becomes expensive, but throwing everything away means rebuilding or regenerating work you might need again.
\nDevelopers are sharing screenshots of disks filled with target/ directories in a matter of hours.
It feels familiar to how Nix users who have had to garbage collect\ntheir /nix/store: which artifacts are still useful, which ones can go, and how to reclaim space without losing what another project still needs.
Casita is our first standalone layer, a content-addressed object store for source code and build artifacts, with shared storage, verification, synchronization, and garbage collection.
\nIt is still pre-release and available as a Rust library and CLI. We’re targeting Linux, macOS, and Windows.
\nRust workspaces and throwaway checkouts can accumulate target/ directories.\nDeleting them discards artifacts a later build might reuse; keeping them\nduplicates bytes across similar projects. Cargo\nand uv cache downloaded\ndependencies, but their caches do not manage source versions and generated\noutputs across projects.
We added an ArtifactStorage interface\nso Cargo can prepare and persist registry archives, Git dependencies, and\nworkspace build outputs through different backends. The filesystem backend\npreserves Cargo’s usual behavior.
The Casita backend imports and restores that content through local IPC, while Cargo still decides what to download and build. This remains experimental: import and restore performance has not yet matched the filesystem backend. The development branch and Cargo guide have the details.
\nThink of Casita’s storage model as a generalized Git object database. Git has blobs, trees, and commits. Casita stores immutable byte blobs and immutable object records: each format defines an object’s identity and its links to other objects. A directory links to its files and subdirectories; a Git commit links to a tree and its parents. Casita follows those links to find a complete saved version.
\nEvery blob has a\nBLAKE3 hash of its\ncomplete bytes. BLAKE3 computes that hash as the root of a Merkle tree. Casita\ncan keep an optional Bao outboard\nwith the tree’s intermediate hashes, so a reader can verify one range against\nthe blob’s hash without reading the whole blob. A full sequential read checks\nthe complete hash. The storage backend may chunk and compress the bytes without\nchanging their address.
\nAn object record gives those bytes meaning and links. For src/main.rs, a file\nrecord points to the blob containing its source code. The src/ directory has\nits own record, which links to that file record and points to a blob encoding\nthe directory entries. These records form a graph above the blobs.
For this filesystem tree, the hashes connect roughly like this:
\nChanging main.rs creates a new file ID, which changes the src/ directory\nID and the IDs of its parent directories. Unchanged files keep their IDs and\nstored bytes. The old blobs and records are never rewritten.
The blob’s BLAKE3 hash and a source format’s hash serve different purposes. A Git commit keeps its native Git ID while Casita addresses its body bytes by their BLAKE3 hash. A Nix archive (NAR) has a SHA-256 hash of its canonical serialization. Casita measures that NAR hash, then stores the archive’s files as a graph of BLAKE3-addressed blobs. The verified object records let Casita traverse the graph without decoding every payload.
\nRead Blob Storage and the repository model for the detailed contracts. The NAR IPC guide shows how to import and restore an archive.
\nAn application gives a saved graph a name, called a\nroot. The root points to one exact object and\nkeeps everything reachable from it. The objects and blobs stay immutable; the\napplication can move or remove the root as its needs change.
\nApplications can save separate versions explicitly. For example, import a\nproject directory after two revisions under projects/app/v1 and\nprojects/app/v2. The imports leave the original working directory in place.\nBoth names keep their versions available, and identical files share one blob.\nAn application could also point projects/app/current at the same object as\nv2, then move that name to a later version without changing either saved\ngraph.
Casita follows links from a root to find its complete graph for synchronization and retention. Removing a name makes objects needed only by that name eligible for garbage collection once active work releases them; files and chunks shared with another root remain.
\nRoots are permanent by default, which suits saved Git histories and releases.\nRebuildable data, such as a Cargo target/ directory, can instead use an\nevictable root:
The CLI can also change retention later with root retention.\nThe Rust API provides set_root_with_retention and\ntouch_root for applications that manage their own cache roots. Marking a root\nevictable does not remove it immediately.
Importers turn inputs into graphs that Casita can verify and retain. The filesystem importer walks a directory; the tar importer reads an archive without extracting it first; and the NAR importer measures a Nix archive’s canonical SHA-256 while storing its files as a graph. The Git importer keeps native Git object IDs and a view of selected branches and tags.
\nEach importer uses the same repository publication and retention rules. Once content is saved under a root, Casita can synchronize it and collect it when no name or active work needs it.
\nCasitar writes a complete saved graph to a portable\n.casitar archive. You can pass it through a file, pipe, or release artifact\nwhen the source repository is unavailable to the receiver. On import, Casita\nchecks every payload and object record, verifies that the archive contains the\nwhole graph, and then publishes the destination roots together. The archive\ncarries object identities and bytes, independent of the source repository’s\npacking and database layout.
The experimental Gix object database adapter reads and writes native Git objects through Casita. Git’s SHA-1 or SHA-256 IDs stay intact while Casita verifies and stores the object bodies and their links. The adapter covers object storage; a complete Git repository also needs its refs, index, and working tree integrated. The example writes a blob, tree, and commit, then reopens the store and reads the commit back.
\nThe companion CasitaFS crate presents a saved filesystem tree as a read-only mount. Existing tools can browse its files without first checking out the whole tree. It uses FUSE on Linux and a native FSKit extension on macOS 26 or later. The macOS extension requires explicit setup for each user.
\nSuppose a second repository already has projects/app/v1. Syncing\nprojects/app/v2 reuses what is there and sends missing content. Compatible\nstores can reuse chunks within changed files too. The destination checks\nincoming objects against their format’s rules and verifies that the whole\nsaved version arrived before it updates the name. An interrupted transfer can\nbe retried without exposing a partial version through that name.
Local repository sync is implemented in the CLI and Rust library. An optional SSH source uses OpenSSH for the connection while the receiving Casita repository still verifies what arrives. Sync adds content; removing destination names and collecting unused data are separate actions. See Synchronization for local, SSH, and selective workflows.
\nIf both projects/app/v1 and projects/app/v2 are named, Casita keeps both.\nRemove the first name and run collection: bytes needed only by v1 can go,\nwhile files and chunks shared with v2 stay. Active readers and writers also\nhold on to the data they are using during collection.
The local CLI can preview a pass with gc --dry-run before running gc.
Automatic collection helps keep a busy disk from filling up. In the standard\nlocal repository, starting a mutation when the filesystem is at least 80% full\ntriggers a nonblocking collection attempt. Casita first reclaims data no root\nor active operation needs. If disk use remains at or above 75%, it releases\nthe least recently used roots explicitly marked evictable, vacuuming after\neach release until use falls below 75% or no eligible roots remain. Permanent\nroots stay, and manual gc preserves every named root, including evictable\nones.
Collection applies to the Casita repository. See Garbage Collection for the retention and recovery rules.
\nTwo runners can use the same S3 bucket and prefix to publish objects and read\nnamed versions. Their payload bytes are immutable, but names and object\nrecords change as new versions arrive. Casita records those changes in\nChroma’s wal3, a write-ahead log stored in S3. Conditional updates to its\nmanifest give competing writers an agreed order for their changes.
\nReaders and writers register durable holds so collection preserves data still\nin use. The S3 profile is experimental and requires the s3 feature; an\nabandoned hold needs explicit recovery. The shared S3 guide\nshows how independent owners can use one repository, and S3\nmaintenance covers collection and recovery.
Casita runs from a source checkout today, but we have not tagged v0.1.0.\nBefore the first release, we need to improve performance where benchmarks show\nbottlenecks, broaden benchmark coverage, and use Casita in more real projects\nand end-to-end workflows. That practical use should expose problems we can fix\nbefore calling 0.1 ready.
The integrations have more work ahead. Cargo’s Casita backend needs faster import and restore before it can match the filesystem backend. The Git object store adapter still needs integration with the rest of a Git repository.
\nFrom a Casita source checkout, install the CLI, then import a directory into the default repository, list its roots, and preview collection:
\nWhen roots and object records are in one Casita repository and the matching blobs are in another, choose the blob source during sync:
\nThe sync guide explains the requirements for a separate blob source.
\nThe Quick Start walks through checkout and inspection, and the Library guide shows the supported Rust API.
\nOur filesystem benchmark compares imports with Git add and commit. In that run, Casita imported the large-file corpus faster, while Git was faster for small-file imports and unchanged re-imports. The full benchmark reference includes methodology and separate native Git measurements.
","headings":[{"level":3,"text":"Cargo","id":"cargo"}]}}