Engine SDKs & game engines

Everything else in this section is about getting data into and out of CAVS Node. This page is about a different job: shipping content to end users with chunk-level delivery, so a player or a client downloads only what changed.

A different family of SDK

These are engine bindings, not platform clients. They wrap the open-source Rust core through a stable C ABI and do chunking, planning, patching and verified reconstruction locally. They do not talk to the CAVS Node API and need no CAVS Node account.

For platform access — uploads, downloads, artifacts, repositories — use the Python or TypeScript SDK instead.

Why you’d want this

A game or desktop client that ships 8 GB of content and patches monthly has a distribution problem: every patch costs the player a large download and you a large egress bill. CAVS turns that into a chunk diff — the client fetches only the chunks it lacks, from a static CDN export, with no game server in the loop.

Measured on real Godot PCKs exported by Godot 4.7: updates 67–70% smaller than downloading the full compressed PCK, and near-free re-downloads.

How the static export works

The CAVS store can be exported as a deterministic, content-addressed object tree — plain immutable files served by GET plus Range:

assets/<oid>/manifest.json      what an asset consists of
chunks/packs/<hash>             immutable packfiles
meta/, index.json               metadata

rsync or aws s3 sync that tree to any CDN and point clients at the URL. Clients read it over plain HTTP with no server-side logic at all. Cache it aggressively — every path is content-addressed, so it’s immutable by construction.

This is the same tree the CAVS LFS agent produces, which means a repository you push through Git can double as your distribution source.

The bindings

Language	Package	Mechanism
Go	github.com/orelvis15/cavs-oss/sdks/go	cgo over the C ABI
Node / TypeScript	@orelvis15/cavs-sdk	koffi over the C ABI
Kotlin / JVM	io.github.orelvis15:cavs-sdk	Java FFM (Panama)
Rust	cavs-sdk-core and the cavs-* crates	direct
CLI	cargo install cavs-cli	the cavs binary

All of them load the same compiled Rust core the CLI uses. None shells out to a subprocess.

The common API

Every binding exposes the same operations:

Method	What it does
analyze	Inspect a payload: format, entropy, chunk behaviour
packDirectory	Pack a build into the CAVS store and export the static tree
preview	Score the routes for one client state and recommend the cheapest
createPlan	Produce a .cavsplan patch
applyPlan	Apply a patch, journaled and resumable
verifyInstall	Verify an installed tree byte-for-byte
benchmark	Measure a build transition
estimateSavings	Project the bandwidth saved

Node

npm install @orelvis15/cavs-sdk

Released builds ship the native library in per-platform packages (@orelvis15/cavs-sdk-linux-x64, -darwin-arm64, -win32-x64, …), resolved automatically. CAVS_SDK_LIBRARY=/path/to/libcavs_sdk.dylib overrides resolution.

import { CavsClient } from '@orelvis15/cavs-sdk';

const cavs = new CavsClient();
try {
  const preview = await cavs.preview({
    oldPath: 'Build_v1',
    newPath: 'Build_v2',
    policy: 'balanced',
  });
  console.log(preview.recommendedRoute);
} finally {
  cavs.close();
}

Every method returns a Promise and accepts onProgress(event) and an AbortSignal. Failures reject with a CavsError carrying a stable .code.

Note

onProgress runs the operation synchronously — koffi can only invoke JS callbacks on the calling thread. Use it in CLIs and build scripts, not on a hot request path. Without it, work runs off the event loop.

Go

go get github.com/orelvis15/cavs-oss/sdks/go

Requires Go 1.21+, a C toolchain (cgo enabled), and the native library (libcavs_sdk.{so,dylib} / cavs_sdk.dll) plus header staged under cavs/native/.

make native   # build cavs-ffi (release) and stage the lib + header
make test

Kotlin / JVM

dependencies {
  implementation("io.github.orelvis15:cavs-sdk:<version>")
}

Uses Java’s Foreign Function & Memory API (Panama), so no JNI shim and no cgo.

CLI

cargo install cavs-cli

The offline toolkit, useful for build pipelines and for understanding what the bindings do:

cavs pack ./Build_v2 --bootstrap        # pack + emit a whole-release artifact
cavs publish-dir ./Build_v2             # a whole release in one pass
cavs preview --old Build_v1 --new Build_v2
cavs route-plan --old Build_v1 --new Build_v2
cavs diff-plan / apply / verify-install
cavs sweep                              # per-payload chunk-profile table
cavs analyze steampipe | analyze-packs | analyze godot-pck
cavs bench full-pipeline                # vs. an external butler pipeline
cavs doctor

Game engine plugins

Engine	Status	What it integrates
Godot 4	released	PCK download and mount via ProjectSettings.load_resource_pack()
Unity	untested reference	AssetBundles and Addressables
Unreal Engine	untested reference	PAK / IoStore (.ucas / .utoc) and cooked content

Godot

Deduplicated content delivery for Godot games without changing the engine or the PCK format. The player downloads only the chunks that changed between versions, the pack is reconstructed byte-identically (verified with SHA-256) and mounted with ProjectSettings.load_resource_pack().

Measured with real Godot 4.7 PCKs: updates −67% to −70% versus the full compressed PCK.

Download the plugin · docs

Unity and Unreal

Reference integrations, not supported releases

Both compile against the CAVS SDK C ABI (cavs_sdk.h, ABI 1.0.0) and mirror the shipping Kotlin (FFM) and Node (koffi) bindings 1:1, but neither has been validated in-editor or on a device. Unity hasn’t been run in the Unity editor; Unreal hasn’t been built with UnrealBuildTool.

Treat them as reference implementations. If you ship on either engine, expect to do integration work — and the maintainers welcome fixes.

Both follow the same shape: install and update builds by downloading only changed chunks straight from a static CDN export, with no game server, then verify and use the reconstructed files at runtime.

Desktop app

A cross-platform GUI (Tauri) for packing, previewing, diffing and verifying builds locally — useful for release engineers who’d rather not use a CLI. Download

Choosing a delivery route

The engine scores every route for one concrete client state and picks the cheapest:

Route	When it wins
no-op	The client is already current
chunks	Normal incremental update
hybrid	Some files by chunk, some by patch
plan	A .cavsplan patch is smaller than the chunk set
sidecar	An optimized per-file .cavspatch beats both
bootstrap	A cold client — one zstd-19 artifact beats the chunk path, and seeds the chunk cache so the next update is already incremental
full	Everything else fails

cavs route-plan prints the scoring under configurable device profiles. That bootstrap behaviour is the interesting one: a first install costs about what a normal download costs, and the client ends up warm.

Verification

The same guarantees as the rest of CAVS: per-chunk BLAKE3, a global Merkle root, per-file SHA-256, and an optional Ed25519 content signature clients can require. Reconstruction is byte-identical or it fails. Interrupted downloads resume with HTTP Range; a corrupt cache is quarantined and repaired in place. Every decoder is fuzzed against byte-flip and truncation sweeps.

Reference

The engine has its own extensive documentation — formats, benchmarks, comparisons against external patching pipelines, and per-plugin guides: github.com/orelvis15/cavs.

Next

• Deduplication explained — the shared mechanism.
• CAVS LFS agent — producing a static export from a Git repository.
• Integrations overview — the platform-side options.