KitOps v1.15.0 just landed, and it is the release where ML packaging learns to speak everyone’s language: full CNCF ModelPack interoperability, new compression tricks that make your artifacts leaner, and built-in support for MCP bundles so you can package entire AI agent toolchains in a single artifact.
Imagine you moved to a new country. You speak the language fluently, but every time you order coffee, the barista looks at you like you are speaking ancient Greek. That has been KitOps and ModelPacks: KitOps knew how to create its own ModelKit format, but when it encountered a ModelPack made by Docker or some other tool, it was lost in translation. v1.15.0 fixes that.
What is KitOps?
KitOps is a CNCF sandbox project that packages machine learning models, datasets, code, and configuration into a single portable artifact called a ModelKit. Think of it as a shipping container for ML — same idea as a Docker image, but designed from the ground up for the messy reality of ML projects where you have weights, training data, inference code, and config files that all need to travel together.
The problem it solves is simple but painful: ML projects are scattered across laptops, notebooks, S3 buckets, and random YAML files that nobody has touched in months. KitOps bundles all of that into one versioned, pushable, pullable package that lives in the same OCI registries you already use for containers. Platform engineers use it to deploy models, data scientists use it to share reproducible experiments, and MLOps teams use it to version everything.
v1.15.0 matters because it adds full CNCF ModelPack interoperability, new compression and layer format options, and MCP bundle support — three features that make KitOps play nicely with the broader ecosystem instead of living in its own walled garden.
What is New
CNCF ModelPack Interoperability
This is the headliner. The CNCF ModelPack format is an emerging standard for packaging ML artifacts, and it is gaining traction fast — Docker CLI recently added support for creating ModelPacks natively. Before v1.15.0, KitOps could only work with its own ModelKit format. If someone handed you a ModelPack created by Docker or another tool, KitOps could not read it.
Now it can. KitOps v1.15.0 can interpret Kitfile-equivalent fields directly from a ModelPack’s configuration and annotations, even if that ModelPack was never touched by Kit. You can also create ModelPacks yourself using the new --use-model-pack flag:
kit pack ./my-project --use-model-packThis means KitOps artifacts and Docker-created ModelPacks are now cross-compatible. You can use whichever tool you prefer, and everything just works together. For teams standardizing on the ModelPack format, this is the feature that removes the last barrier to adoption. PR #1202
New Compression and Layer Format Options
By default, KitOps packages each layer — model weights, datasets, code — as an uncompressed tarball. It is a sensible default: fast, simple, predictable. But sometimes you want options, and v1.15.0 delivers two big ones.
Zstandard compression is now available alongside the existing gzip option. Zstd gives you better compression ratios with dramatically faster decompression, which matters when you are pulling multi-gigabyte model weights:
kit pack ./my-project --compression=zstdRaw layer format is the more interesting addition. Instead of wrapping every file in a tarball, Kit can now package single files as-is — no tar wrapper at all. The practical benefit is significant: the layer’s DiffID (and digest, when uncompressed) matches the actual SHA256 sum of the file on disk. That makes it trivial to track exactly which files are stored in which ModelKits, which is a big deal for auditing and deduplication:
kit pack ./my-project --layer-format=rawFor anyone managing storage costs across dozens of model variants that share the same datasets, this feature alone could save real money. PR #1202
MCP Bundle Support in ModelKits
The Model Context Protocol (MCP) has become the standard way to connect AI agents to external tools and data sources. MCP bundles (files with a .mcpb extension) are how MCP servers get distributed and shared. Until now, there was no first-class way to package them alongside the models that use them.
KitOps v1.15.0 adds a new mcpServers section to the Kitfile, letting you bundle MCP servers directly into a ModelKit. This means you can package a model, its training data, its inference code, and the MCP servers it depends on — all in one artifact:
manifestVersion: v1.0.0
model:
path: my-agent-model.safetensors
mcpServers:
- path: ./tools/web-search.mcpb
- path: ./tools/database-query.mcpbThis turns KitOps from a model packager into a complete AI agent distributor. You can build, version, and ship entire agent stacks — model plus toolchain — as a single pullable artifact. If you are building agent-based systems and struggling with reproducibility across environments, this is the feature you have been waiting for. PR #1214
Bug Fixes
- Auth headers for push operations have been improved, making registry authentication more reliable across different providers. PR #1194
- KITOPS_HOME is now respected in the library config path, so custom installations work correctly. PR #1189 (first contribution by @puneetdixit200)
- Image manifest mediatype is now set on manifests created by Kit, improving compatibility with strict OCI registries. PR #1218
- Missing content handling in local list and remove operations is now more tolerant of edge cases. PR #1217
KitOps v1.15.0 is the release where ML packaging stops being proprietary: ModelPack interoperability means your artifacts work everywhere, and MCP bundle support means you can now ship entire AI agent stacks as a single artifact.
