Documentation
oci-bai tracks every model, fine-tune, dataset, runtime, and dependency in a single artifact graph — with lineage, provenance, and deduplication built in. Push through the gateway with any OCI-compatible tool; the graph builds itself.
Getting started
Push your first image, explore the commit graph, and run your first search.
Find images by package, CUDA version, model format, or any combination.
Guides
Trace what a version was built on and see how much storage it shares with its parent.
Every oci-bai command and its flags.
Web dashboard
The dashboard is the visual control plane for the same graph the CLI reads. It has two lenses: engineer for version families, diffs, search, and provenance; and operator for fleet health, operation history, optimization, and cost/SLO.
Lightweight example usage
For a local stack, push through the gateway, then use either the CLI or dashboard.
docker tag my-image:latest localhost:8080/rl-gym-env:cartpole docker push localhost:8080/rl-gym-env:cartpole oci-bai --repo rl-gym-env log cartpole oci-bai --repo rl-gym-env diff cuda-base cartpole --depth package oci-bai search "format==safetensors cuda>=12.4"
In the dashboard, open the project picker, choose rl-gym-env, then use Versions for the graph, Compare for diffs, Find for dependency search, and Provenance for derivation.
How it works
Every image pushed through the gateway creates a commit in the artifact graph. The graph records the manifest, the files, derivation edges to parent images, and the full audit trail. It is the source of truth; the backing registry is just storage.
When you push fifty fine-tunes of the same base model, oci-bai deduplicates storage automatically — only the novel parts of each fine-tune are stored. Model weight files (safetensors, GGUF) are detected at push and are immediately searchable via format==safetensors.