KitOps: putting model weights in an OCI registry

Why a registry is the right place for a model

KitOps is built on the same OCI technology that underlies containers, and the pitch is that everything a model needs becomes a versioned, layered artifact in a registry you already operate. The README is direct about the audience: it presents the tool as the preferred option for packaging, versioning and managing AI assets in security-conscious enterprises, governments and cloud operators who need to self-host models and agents.

That framing explains the design better than the feature list does. Once a model lives in a registry, it inherits everything the registry already provides. You get content addressing through SHA-256 digests, immutable tags, replication between regions, and the same pull-through caching that keeps container starts fast. The README lists ModelKits as tamper-proof because every component is protected by those digests, signable with full Cosign compatibility, natively stored and retrieved in all major OCI container registries, and selectively unpacked so you can pull only the model or only the dataset.

Governance is the project's justification. KitOps is governed by the CNCF, the same organisation behind Kubernetes, OpenTelemetry and Prometheus, which matters if you need a vendor-neutral story rather than one more proprietary model store.

ModelKit and ModelPack are two formats, not one

Kit supports two interchange formats and handles both transparently. A ModelKit is the native bundle: a self-contained, immutable package that can include agents, model weights, MCP servers, datasets, prompts, experiment run results and hyperparameters, metadata, environment configurations and code. A ModelPack is the vendor-neutral CNCF format defined in the modelpack specification, of which KitOps describes itself as the enterprise implementation.

The distinction is not academic. v1.15.0, published 2026-06-25, improved ModelPack handling so that when Kit meets a ModelPack it did not generate, it can interpret the fields normally found in a Kitfile from the ModelPack's configuration and annotations. The release notes are explicit that not all KitOps features are supported by ModelPacks currently, and the `pack` command takes a `--use-model-pack` flag to choose the format. The stated goal is that you should be able to use ModelPacks with KitOps regardless of how they were created, and the notes mention the Docker CLI recently gained the ability to create ModelPacks that are now compatible.

Contributing companies to the ModelPack specification include Red Hat, PayPal, ANT Group and ByteDance, which tells you who is invested in that half of the design.

The Kit CLI is seven commands and a Kitfile

The unit of configuration is the Kitfile, which defines where each artefact lives inside a ModelKit. Rather than hand-write one, the quick start has you navigate to your project directory and run `kit init .` to auto-generate it.

The lifecycle the README describes takes three commands after that:

kit init .
kit pack
kit push

The full command set adds `kit unpack` to extract all or specific layers, `kit pull` to retrieve from any OCI registry, `kit diff` to compare two ModelKits, `kit list` to enumerate what is available, and `kit inspect` to view contents without unpacking. The README stresses that all of these work across both formats. There is also an import path from HuggingFace for pulling models directly into a ModelKit, and a PyKitOps Python SDK for people who want to drive this from code rather than the command line.

The Go module tells you what the implementation leans on. It requires `oras.land/oras-go/v2` v2.6.2, which is the OCI registry client, along with the Open Container Initiative digest and image-spec libraries, `cobra` for the command line, `klauspost/compress` for layer compression, `moby/patternmatcher`, the AWS SDK v2 for S3, a progress bar library, and the modelpack specification module itself.

module github.com/kitops-ml/kitops

go 1.25.11

Signing, attestations and the SLSA predicate

The security story is where this stops being a file format and starts being a supply chain tool. The README describes three escalating levels of use. At the first, teams version a model or agent when it is ready for staging or production, so a ModelKit is the immutable handoff unit that keeps datasets, weights and config synchronised and trackable. At the second, teams in regulated industries scan and gate models before they reach production: build a ModelKit, sign it with Cosign, run security scans, attach reports as signed attestations, and allow only attested ModelKits to move forward. At the third, mature teams extend the same mechanism to development, storing every milestone such as a new dataset, a tuning checkpoint or a retraining event as its own versioned ModelKit.

The release history shows this tightening in concrete terms. v1.14.0, published 2026-05-21, added SLSA attestation generation for `kit import`. The new `--attestation-output` flag produces a SLSA Provenance v1 predicate recording what was imported, which can then be pushed alongside the ModelKit to the registry, for example by using cosign. That same release extended the `remotePath` field from S3 URLs to ModelKit references, so a dataset layer can point at another ModelKit rather than embedding its bytes.

v1.13.0 went in a different direction, adding `kit unpack --as-skill` to install agent skills from a ModelKit into tools such as Codex and Claude Code. The default is global installation across every agent on the machine, which is worth knowing before you run it on a workstation.

Datasets that live somewhere else

Versioning a model does not require versioning its training data, and the project treats remote data as a first-class case. Support for datasets stored in S3 buckets arrived via the `remotePath` field in v1.12.0, and v1.14.0 extended that same field to accept ModelKit references alongside S3 URLs.

The behaviour is that when packing, the local contents of the declared directory are ignored and not included as a layer, with the remote location recorded instead. The release notes illustrate it with a Kitfile in which a dataset entry carries a `path` and a `remotePath` pointing at a registry reference. For a team whose datasets are terabyte-scale, that is the difference between a workable versioning story and an unusable one, since model weights are typically the smaller half of the artefact.

The related compression work landed in the same window. v1.15.0 added additional format and compression options for artefact layers, which matters because the natural instinct is to gzip everything and the more useful move is often to keep weights in a format the inference stack can memory-map directly.

The repository tree suggests the project is run with agent tooling in mind, since `AGENTS.md` and `CLAUDE.md` sit at the top level next to `CONTRIBUTING.md`, `GOVERNANCE.md`, `MAINTAINERS.md` and `SECURITY.md`, alongside a `frontend/`, `cmd/`, `pkg/` and `testing/` layout.

Where the README stops and the site takes over

The README is an argument with a link list attached. It covers what a ModelKit is, why OCI is the substrate, the three usage levels, the CLI surface and the CNCF relationship, and then routes every operational detail to kitops.org: the installation page for macOS, Windows and Linux, the getting started guide, the HuggingFace import page, the CI/CD integration guide, the ModelKit reference, the Kitfile overview, the CLI reference, the security documentation, and a use cases page.

There is a GitHub-only fallback for people who want the newest code, with build-from-source steps in the installation docs. The README also points at pre-built ModelKits to explore, hosted as quick starts for LLMs and computer vision models.

For evaluating the project, the things worth reading beyond the README are the security documentation and the attestation flow, because those decide whether it can sit in a release pipeline, and the CLI reference, because the flags carry most of the real behaviour. At 1,419 stars, 185 forks and 49 open issues, this is an active project with a real governance structure rather than a solo experiment. The last push was on 2026-09-16, and the newest release, v1.15.0, came out on 2026-06-25.

Editorial conclusion

KitOps is at its best when an organisation already runs an OCI registry and treats model weights as untracked artefacts that ought to be versioned, signed and auditable like any other build output. The ModelKit format is the better documented path, and the CLI commands that matter are few enough to learn in a sitting: init, pack, push, pull, diff, inspect. Two limits deserve attention. Not every KitOps feature works through the ModelPack format, which the project states plainly in the v1.15.0 notes, and the skill unpacking added in v1.13.0 installs globally across agents unless you scope it with a tool name or a directory. Start by packing one model directory and pushing it to a registry you control, then read the security and attestation documentation before making it a gate.

Frequently asked questions

Official sources

1. kitops-ml/kitops on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases