ModelKits do both. With a ModelKit, you can package all the parts of your AI project in one shareable asset, and tag them with a version. ModelKits were designed for the model development lifecycle, where projects are handed off from data science teams to application teams to deployment teams. Versioning and packaging makes it easy for team members to find the datasets and configurations that map to a specific model version. You can read more details about KitOps in our overview.

The easiest way to get started is to follow our Quick Start, where you’ll learn how to:

• Package up a model, notebook, and datasets into a single ModelKit you can use with your existing tools
• Share the ModelKit with others through your public or private registry
• Grab only the assets you need from the ModelKit for testing, integration, local running, or deployment

Yes [choir sings hallelujah], each ModelKit includes SHA digests for the ModelKit and every artifact it holds so you can quickly see if something changed between ModelKit versions.

Increased speed: Teams can work faster with a centralized and versioned package for their AI project coordination. ModelKits eliminate hunting for datasets or code, and make it obvious which datasets and configurations are needed for each model. Handoffs can be automated and executed quickly and with confidence.

Reduced risk: ModelKits are self-verifying. Both the ModelKit itself and all the artifacts added to it are tamper-proof. Anyone can quickly and easily verify when something may have changed.

Improved efficiency: Models stored in ModelKits can be run locally for experimentation or application integration, or packaged for deployment with a single command. Any artifact in a ModelKit can be separately pulled saving time and space on local or shared machines. This makes it easy for data scientists, application developers, and DevOps engineers to find and grab the pieces they need to do their job without being overwhelmed with unnecessary files.

ModelKits store their assets as OCI-compatible artifacts. This makes them compatible with nearly every development and deployment tool and registry in use today.

ModelKits can be stored in any OCI-compliant registry - for example in a container registry like Docker Hub or Jozu Hub, or your favorite cloud vendor’s container registry, they can even be stored in an artifact repository like Artifactory.

Yes, it is licensed with the Apache 2.0 license and welcomes all users and contributors. If you’re interested in contributing, let us know.

No, ModelKits complement containers - in fact, KitOps can take a ModelKit and generate a container for the model automatically. However, not all models should be deployed inside containers - sometimes it’s more efficient and faster to deploy an init container linked to the model for deployment. Datasets may also not need to be in containers - many datasets are easier to read and manipulate for training and validation when they’re not in a container. Finally, each container is still separate so even if you do want to put everything in its own container it’s not clear to people outside the AI project which datasets go with which models and which configurations.

Models and datasets in AI projects are often 10s or 100s of GB in size. Git was designed to work with many small files that can be easily diff’ed between versions. Git treats models and datasets stored in LFS (large file storage) as atomic blobs and can’t differentiate between versions of them. This makes it both inefficient and dangerous since it’s easy for someone to tamper with the models and datasets in the LFS without Git knowing. Finally, once you use LFS, a clone is no longer guaranteed to be the same as the original repo, because the repo refers to an LFS server that is independent of the clone and can change independently.

KitOps is the only standards-based and open source solution for packaging and versioning AI project assets. Popular MLOps tools use proprietary and often closed formats to lock you into their ecosystem. This makes handoffs between MLOps tool users and non-MLOps tool users (like your application development and DevOps teams) unnecessarily hard. The future of MLOps tools is still being written, and it’s likely that many will be acquired or shut down and the cost of moving projects from one proprietary format to another is high. By using the OCI standard that’s already supported by nearly every tool on the planet, ModelKits give you a future-proofed solution for packaging and versioning that is compatible with both your MLOps tools and development / DevOps tools so everyone can collaborate regardless of the tools they use.

Enterprise support for ModelKits and the Kit CLI is available from Jozu.

KitOps is the enterprise implementation of the ModelPack specification. KitOps was built first, then it's approach was formalized into the CNCF's ModelPack spec with contributors from Jozu, Red Hat, PayPal, ANTGroup, and ByteDance. The CNCF's KitOps' ModelKits adhere to the CNCF ModelPack specification for an open ML packaging and versioning standard.

KitOps can package and version AI/ML projects as a ModelPack implementation by using the kit pack . --use-model-pack command. All other Kit CLI commands will work with this CNCF model packaging without change.

CNCF governance ensures vendor neutrality and an enterprise ML standard - organizations won't need to rebuild tooling when changing vendors. Unlike vendor-specific packaging, versioning, and model registry approaches that mimic openness, KitOps was designed from day one to be community-driven. Enterprises get a standard that works with existing container infrastructure and won't lock them in when MLOps vendors are consolidated.

KitOps focuses on packaging and versioning, not orchestration or serving. It complements other AI/ML tools rather than competes: KitOps integrates with Kubeflow pipelines, serves models directly to KServe via kit:// URIs, and works with any Kubernetes distribution. Other CNCF ML tools handle what happens after the artifact is delivered.

KitOps stores each asset type (model, datasets, code, prompt, and config) as a separate OCI layer with its own SHA-256 digest. This enables selective unpacking - pull only the model weights without downloading 100GB of training data. Now models are packaged using standard OCI protocols and work with any OCI 1.1+ registry.

Yes. ModelKits work with Amazon ECR, Azure Container Registry, Docker Hub, GitHub Packages, GitLab Container Registry, Google Artifact Registry, Harbor, JFrog Artifactory, Quay.io, and others. Use your existing registry infrastructure - no new tooling required. It effectively turns your container registry into an AI registry.

Security: content-addressed storage makes artifacts tamper-proof, with Cosign compatibility for cryptographic signing.

Operations: the same artifact deploys identically from laptop to production cluster. Compliance: immutable packages with full audit trails.

Infrastructure: leverage existing container registry investments, scanning tools, and access controls.

This is OCI standards AI that leverages the container standards you already use.

ModelKits create AI / ML reproducibility by bundling model, code, datasets, prompts and config into a single versioned artifact. Every unpack operation verifies integrity automatically. Tags like :champion or :v2.1 apply to the complete artifact, not scattered pieces - eliminating the "which version of which asset?" problem that breaks reproducibility and adds unnecessary risk to deployments.

Yes. KitOps packages any AI/ML component — models, datasets, code, configuration, MCP server definitions, agent skills, guardrail configs, and policies — as a single versioned OCI artifact. MCP servers and agent skills get the same cryptographic signing, scanning, and governance as your models.

OCI artifacts give you immutable versioning, cryptographic signatures, supply chain scanning, and content-addressable storage — the same infrastructure you already use for container images. Git repos work for source code, but production AI deployments need the tamper-evidence, provenance, and policy gating that OCI provides.

KitOps is the reference implementation of ModelPack, the CNCF specification for vendor-neutral AI/ML packaging. KitOps also supports its own ModelKit format with broader artifact coverage including MCP servers, agent skills, and policies.