One API for AI, CI/CD
and build pipelines.
CAVS Hub stores large artifacts once and delivers only the bytes a client is missing — content-addressed, deduplicated, versioned and traceable. These SDKs let your pipelines talk to the same canonical API the CLI uses: one auth model, one data plane, one set of metrics.
One contract.
Every ecosystem.
A Python training job, a GitHub Actions release, and (soon) an MLflow run all share the same API, the same permission model, the same data plane and the same metrics — because every SDK implements the one canonical contract.
Content-addressed dedup
Each object's address is the lowercase hex sha256 of its bytes (the oid). Objects already stored are skipped on upload, so you only ship what's new.
Streaming upload & download
Files stream directly to object storage over presigned URLs. Hashes are computed by streaming — never by loading whole files into memory — and verified on the way down.
Typed errors & retries
A shared exception hierarchy (AuthenticationError, QuotaExceededError, RateLimitError…) with automatic backoff on 429/5xx that honours Retry-After.
Runs & lineage rolling out
Attach uploads to a run and record produced/consumed edges, so every artifact traces back to the pipeline that made it and the inputs it consumed.
Same API as the CLI
The Go server is the reference implementation and the Rust CLI is the reference client. The SDKs implement the exact same wire contract — no drift.
Security by default
Tokens are redacted from logs and errors, TLS is validated (custom CA via CAVS_CA_BUNDLE), downloads are checksum-verified, and directory expansion guards against path traversal.
Install, authenticate, upload.
Three steps to your first content-addressed upload. Pick a language on the left; the flow is identical everywhere.
Install
pip install cavs or npm install @cavsnode/cavs-sdk.
Authenticate
Export a service-account key as CAVS_TOKEN and your Hub URL as CAVS_API.
Upload
Call upload() with a path, project, name, kind and version.
What's shipping now.
Two SDKs and a GitHub Action are in this repo today. More integrations are on the roadmap.
| Package | Language / runtime | Status | Guide |
|---|---|---|---|
cavs | Python 3.9+ | stable | Python SDK → |
@cavsnode/cavs-sdk | TypeScript / Node 18+ | stable | TypeScript SDK → |
cavs upload-artifact | GitHub Action | stable | GitHub Action → |
mlflow-cavs, cavs-kfp, Airflow, cavs-go, CAVS.SDK, Unity, Unreal | — | planned | Roadmap → |
Questions.
A deduplicating artifact store for AI, CI/CD and build pipelines. It stores large artifacts once, addressed by content, and delivers only the bytes a client is missing — versioned and traceable. These SDKs are the official clients for its API.
Every object is addressed by the lowercase hex sha256 of its bytes — the oid. When you upload, the SDK reports each object's oid and size; the server replies which already exists, and the SDK skips the transfer for those. Uploading an unchanged file costs no bytes.
No. Bytes stream directly to object storage over presigned URLs — the control plane only coordinates the session. Downloads work the same way and are verified against the oid before the file is written.
Yes. Set CAVS_API to your Hub's base URL (default https://cavsnode.com). Everything else — auth, endpoints, the cavs:// URI scheme — is identical.
The SDK surfaces are designed against the canonical contract. Server-side runs, lineage, cavs:// resolve and the service-account management API are rolling out; core upload/download, versioning and dedup work today.
Ship your first artifact today.
Install an SDK, export a service-account token, and run your first content-addressed upload in minutes.