Store overview

The full reference lists every field on every store. This page is the map you need before that list is useful: what a store actually is, the two families every store falls into, and the compositions people actually run in production.

What a store is

A store is a named, pluggable backend for CAS or AC data. You declare each one once in the top-level stores array, then reference it by name from servers, workers, or from inside another store:

{
  stores: [
    { name: "CAS_MAIN_STORE", filesystem: { /* ... */ } },
  ],
  servers: [{
    services: {
      cas: [{ instance_name: "main", cas_store: "CAS_MAIN_STORE" }],
    },
  }],
}

The store's type is whichever key you put inside its object: filesystem, memory, compression, fast_slow, and so on. NativeLink picks the implementation from that key; everything else in the object is that implementation's config. The set of legal keys is the variant list of a single enum, so the reference below and the parser cannot disagree.

Two families

Every store type is either terminal (it actually holds or fetches bytes) or a wrapper (it adds behavior in front of another store, which it embeds as a nested StoreSpec). Wrappers nest arbitrarily deep: a verify can wrap a compression, which wraps a fast_slow, which wraps two more terminal stores:

Reads and writes flow through every wrapper in order. Nothing about the client changes; it still speaks plain CAS/AC RPCs against whatever store name the server exposes.

Terminal stores: where bytes actually live

Every implementation in this table lives in nativelink-store/src.

Wrapper stores: behavior layered on a backend

The nested-StoreSpec shape each wrapper takes (one backend, two named backends, or N) is declared alongside the terminal specs.

Choosing a terminal backend

Common compositions

Single-node dev cache: no wrapping at all. See Configuration → Stores.

Validated, compressed, tiered CAS: the shape most self-hosted production clusters converge on:

{
  name: "CAS_MAIN_STORE",
  verify: {
    verify_size: true,
    verify_hash: true,
    backend: {
      compression: {
        compression_algorithm: { lz4: {} },
        backend: {
          fast_slow: {
            fast: { memory: { eviction_policy: { max_bytes: "2gb" } } },
            slow: {
              experimental_cloud_object_store: {
                provider: "aws",
                region: "us-east-1",
                bucket: "nativelink-cas",
              },
            },
          },
        },
      },
    },
  },
}

Sharing one store instance across two trees: use ref_store instead of declaring the same backend twice:

{
  stores: [
    {
      name: "FS_CONTENT_STORE",
      filesystem: { content_path: "/var/lib/nativelink/cas", temp_path: "/var/lib/nativelink/tmp" },
    },
    {
      // The worker's fast/local tier and the AC's fast tier now share
      // one filesystem store instead of each scanning their own copy.
      name: "AC_MAIN_STORE",
      fast_slow: {
        fast: { ref_store: { name: "FS_CONTENT_STORE" } },
        slow: { noop: {} },
      },
    },
  ],
}

FAQ

What's next

• Configuration reference: every field, default, and JSON5 example for every store type above.
• Configuration: how stores fit alongside servers, schedulers, and workers.
• Production configuration: the store composition a real cluster uses end to end.