What is CAVS Node?

CAVS Node is a managed platform for the files that don’t fit comfortably in Git: AI models and checkpoints, datasets, media bundles, disk and container images, game and application assets, build artifacts, backups and patches.

It gives those files what source code already has — versioning, history, access control, an audit trail, a browsable UI and a real API — while storing and transferring them at a fraction of their nominal size.

The problem it solves

Git tracks text brilliantly and binaries badly. Git LFS moves the binaries out of the object database, but it still stores and transfers every version of every file whole. Change 3 MiB inside a 22 MiB checkpoint and you pay for 22 MiB again — on the server, on the wire, and on every machine that pulls.

CAVS Node splits objects into content-defined chunks, compresses them, and stores each unique chunk once:

Operation	Vanilla Git LFS	CAVS Node
Push a 22 MiB file with ~3 MiB changed	22 MiB stored + sent	~3.3 MiB stored + sent
Pull that version where the previous one is cached	22 MiB	~0.5 MiB
Store 10 similar 1 GB checkpoints	~10 GB	dedup-dependent, typically a fraction

Measured, not modelled

Those figures come from the reproducible end-to-end suite in the open-source engine (core/cavs-lfs-agent/e2e and bench/). Your own numbers appear in the dashboard’s Benchmarks tab after the first push — CAVS records the real bytes moved for every transfer. See Storage insights.

What you get

A repository model you already understand

Organizations own repositories. Repositories hold objects, commits, branches, tags, releases and activity. Roles and per-repository collaborator overrides control who can read, push and administer.

Two data-plane paths

A Git-native path (Git LFS, with or without the CAVS transfer agent) and a direct API path (upload sessions + presigned URLs) used by the SDKs, the CLI and CI.

Storage you choose

Managed storage — CAVS runs the bucket on Cloudflare R2. Or Bring Your Own S3 — the bytes stay in your account, CAVS keeps only metadata.

Observability of your own data

Logical vs physical bytes, dedup ratio, folder-level breakdowns, transfer benchmarks, repository health checks, storage recommendations, usage series and an audit log.

How the pieces fit

CAVS Node is the managed product. It is built on an open-source engine and shipped with a CLI and a set of client SDKs:

Component	What it is	Repository
CAVS Node	The platform: API (control + data plane), workers, dashboard. This is what cavsnode.com serves.	private
CAVS engine	Open-source Rust core: chunking, packing, store formats, cavs-lfs-agent, the cavs local toolkit, engine SDKs.	orelvis15/cavs
cav CLI	Thin Rust client for the platform: login, connect, index, upload, download, verify.	orelvis15/cavs-hub-cli
Client SDKs	Python and TypeScript clients for the platform API, plus a GitHub Action.	orelvis15/cavs-sdks

Two families of SDK, don't mix them up

The platform SDKs (pip install cavs, npm i @cavsnode/cavs-sdk) speak HTTP to CAVS Node — that’s what most people want. The engine SDKs in the open-source repo (Go, Node, Kotlin) are FFI bindings over the Rust chunking and fetch engine, for embedding CAVS delivery inside your own application or game client. See Engine SDKs.

What CAVS Node is not

• Not a compressor or a codec. It sits on top of your formats. Bring the best format for your bytes — safetensors, Parquet, PNG, PCK, squashfs — and CAVS moves and stores them efficiently.
• Not a Git host. Your source and history stay on GitHub, GitLab or wherever they live. CAVS replaces the LFS storage and transfer layer and builds a read-only index of your Git metadata so the dashboard can show files, commits and branches.
• Not a general-purpose object store. Objects are content-addressed by their SHA-256; there is no mutable path namespace in the data plane. Paths come from the Git index layered on top.

Where to go next

How it worksThe architecture, the two data paths, and what happens on a push.

QuickstartFrom zero to a deduplicated push in about five minutes.

Core conceptsOrganizations, repositories, oids, generations, snapshots, storage modes.

Choosing an integrationCLI, Git LFS, SDK, CI or raw HTTP — a decision table.