github.com/kitops-ml/kitops

Welcome to the v1.15.0 release of Kit! This release improves support for the CNCF ModelPack format, adds support for more options when packing ModelKit data, and adds support for MCP bundles.

New Features

Improved CNCF ModelPack support

Kit is now better at handling CNCF ModelPack artifacts. When working with a ModelPack that was not generated by Kit, Kit can interpret the fields normally found within a Kitfile from the ModelPack's configuration and annotations.

To use Kit to package artifacts in the ModelPack format instead of ModelKit, you can use the flag --use-model-pack for the pack command. Note that not all KitOps features are supported by ModelPacks currently.

Ultimately, you should be able to use ModelPacks with KitOps, regardless of how they were created. For example, the Docker CLI recently added support for creating ModelPacks, and those are now compatible with KitOps.

For more details, see PR #1202

Additional format and compression options for artifact layers

By default, Kit packages each layer (model weights, datasets, code, etc.) as an uncompressed tarball, which provides a good tradeoff in terms of usability, size, and speed. With KitOps v1.15.0, the following extra options are now available while packing ModelKits (or ModelPacks)

• Compression options: in addition to the existing --compression=gzip option, KitOps now supports using Zstandard compression via the flag --compression=zstd.

• Layer format options: instead of packaging files and/or directories as tarballs, Kit can now package single files as-is -- i.e. with no tar wrapper. The primary benefit of the raw format is that the layer DiffID (and digest, for the no compression case) match the actual SHA256 sum of the file on disk, making it easier to track which files are stored in which ModelKits.

  To enable raw layers, use the flag --layer-format=raw on the pack command, though note that this flag currently applies to all layers in the Kitfile.

These changes were added as part of improving ModelPack support; for more information, see PR #1202

MCP support in ModelKits

With Kit v1.15.0, the Kitfile now has a mcpServers section, which can be used to package MCP bundles (.mcpb) files in a new layer format. These bundles are a common way to distribute MCP servers, and adding them to the Kitfile allows for building automation and management around MCP servers specifically.

For more details on how MCP bundles are handled, see PR #1214

Bug Fixes

• Improve auth header handling for push operations by @amisevsk in #1194
• Respect KITOPS_HOME in library config path by @puneetdixit200 in #1189
• Add image manifest mediatype to manifests created by Kit by @amisevsk in #1218
• fix: tolerate missing content in local list and remove by @gorkem in #1217

New Contributors

• @puneetdixit200 made their first contribution in #1189

Full Changelog: v1.14.0...v1.15.0

Welcome to the v1.14.0 release of Kit! We've added some exciting new features and improvements.

New Features

SLSA attestation generation for kit import

KitOps can now generate attestations when running kit import, saving information about what was imported. The new flag, --attestation-output, can be used to generate a SLSA Provenance v1 predicate for the import process, which can then be pushed alongside the ModelKit to your OCI registry (e.g. by using cosign)

For more information, see PR #1175 by @gorkem.

Support for remote ModelKit references for datasets

Version v1.12.0 added support for datasets stored in S3 buckets via the remotePath field. In version v1.14.0, we are extending the remotePath field to support ModelKit references in addition to S3 URLs.

To illustrate how this changes the behaviour of Kit, consider the Kitfile

manifestVersion: v1.0.0
model:
  path: my-model.safetensors
datasets:
- path: my-dataset/
  remotePath: docker.io/jozu/my-dataset:latest

• When packing this ModelKit, the contents of my-dataset/ will be ignored and not included as a layer in the manifest
• When pushing this ModelKit, only the layer generated for the model will be pushed, saving bandwidth and potentially storage.
• When pulling, the docker.io/jozu/my-dataset:latest ModelKit will also be pulled.
• When unpacking, if the --include-remote flag is provided, the contents of docker.io/jozu/my-dataset:latest will be unpacked into my-dataset/. This is similar to running kit unpack docker.io/jozu/my-dataset:latest -d my-dataset/.

This can be used to group multiple datasets together into one ModelKit for easier management, or to link datasets to model weights without requiring the datasets be pushed and pulled alongside the model.

For details on this change and more explanation, see PR #1185

More control over output of kit init with --depth flag

With v1.14.0, the output of kit init can be adjusted slightly to include more or less information. Previously, kit init would analyze the files and directories in its target and attempt to group each based on whether it seemed like a dataset, model, code, documentation, or prompt element. With the new --depth flag, this process can continue into subdirectories of the target directory, adding more individual layers to the Kitfile before starting to group entries into whole directories.

This may be useful if a subdirectory contains many large files that ideally should not be included in a single layer. When the flag is not specified, it defaults to --depth=0, which is similar to how kit init behaved prior to this change.

For more details and examples, see PR #1176

Significant Changes

• During kit init, the generation of a "catch all" code layer, that contains all other files in the directory has changed. You should only see a layer with path: '.' when there are more than 5 files in the base directory. Additionally, when a "catch all" code layer is generated, it no longer replaces all previously-generated code layers. To see the discussion around this change, see #1176 (comment)

• KitOps now sets the org.opencontainers.image.created annotation on manifests created when running kit pack. This means that re-packing a ModelKit will result in a different overall digest hash, though individual layers should retain reproducible digests (saving the need to re-push them). For more information, see PR #1139 by @itniuma2026.

• Unpacking ModelKits as skills now supports auto-detecting more tools and agents. See PR #1181 for more details

Bug Fixes

• Starting in v1.14.0, KitOps will be less intrusive with notifications for new versions. If you are running an old version, you should only see a notification once every 24 hours or if a new version is released. See PR #1188 for details

New Contributors

• @itniuma2026 made their first contribution in #1139

Full Changelog: v1.13.0...v1.14.0

Welcome to the v1.13.0 release of Kit! In this release, we've improved how KitOps handles ModelKits that contain AI agent skills.

New Features

Support for unpacking skills to agent directories directly

The kit unpack command now supports flag --as-skill. When specified, any skills within that ModelKit are automatically installed for any AI tools (e.g. Codex, Claude Code) that you have installed on your system. By default, Kit will install skills to all agents, globally.

To install skills only for a specific tool, e.g. Claude Code, specify the tool name as an argument for the --as-skill flag:

kit unpack <my-modelkit> --as-skill=claude-code

To install the skill to a local directory rather than globally, the --directory flag can be used to add skills only for the specified directory.

For more details, see PR #1158

Full Changelog: v1.12.0...v1.13.0

Note: the v1.12.0 had to be re-pushed to address an issue in our release pipeline: #1154

Welcome to the v1.12.0 release of Kit! We've added some exciting new features and improvements.

New Features

Support for datasets stored remotely in S3 buckets

KitOps can now reference datasets stored in S3 buckets, avoiding the need to include them in ModelKit packages. If you are already storing datasets in S3, you can now link to them in your Kitfile:

datasets:
  - name: my-remote-dataset
    path: local/path/for/unpack
    remotePath: s3://<bucket-name>/<bucket-key>
    remoteHash: <ETag for remote object>

if you pack this Kitfile into a ModelKit, the my-remote-dataset dataset will not be included in the ModelKit artifact -- instead, Kit will verify the object in the S3 bucket. When this ModelKit is unpacked, Kit will download the dataset from S3 to the path specified.

For more information, see issue #887 and PR #1085

Skill support for kit init

Kit now automatically detects agent skills when running kit init. If a directory contains a SKILL.md file, kit init will generate a Kitfile that includes that directory as a prompt, allowing for it to be easily unpacked independently from the rest of the ModelKit. Kit will also parse the frontmatter on SKILL.md to retrieve metadata related to the skill, and include that in the Kitfile, if applicable.

This is also preparation for future changes coming to Kit, which will allow unpacking ModelKits as agent skills, automatically adding the skill directory to your agent of choice (e.g. Claude Code, Cursor, etc.)

For more information, see PR #1092 by @gorkem.

Huggingface datasets support for kit import

Kit import can now import datasets from huggingface repositories automatically. To import from a dataset, use either kit import datasets/<hf-repository> or the full huggingface URL for import.

For more information, see issue #1004 and PR #1007

Thanks to @arnab2001 for this contribution!

Generate Kitfiles for remote repositories

Previously, kit init only worked on local directories. This caused friction when importing a model from Huggingface -- you could see the Kitfile and edit it during the import but it was not possible to get a Kitfile before running kit import. Thanks to @arnab2001, you can now pass huggingface URLs to kit init and have a Kitfile you can edit before passing it into kit import via the --file flag.

For more information, see issue #1055 and PR #1074

Filtering output of kit list

The kit list command now accepts a --filter flag that can be used to filter which ModelKits are included. This flag has the same semantics as --filter for kit unpack -- for example you can use kit list --filter=docs to list ModelKits that have docs layers. If you have a lot of ModelKits saved locally (or are looking at large remote repositories) this makes finding the ModelKit you're after much easier.

For more information, see issue #1091 and PR #1094

Thanks @rishi-jat for this contribution!

Significant Changes

• Add pluggable Logger interface to output package by @gorkem in #1100

Bug Fixes

• fix(harness): prevent OOM in verifyChecksum using stream by @krsatyamthakur-droid in #1125

New Contributors

• @arnab2001 made their first contribution in #1007
• @rishi-jat made their first contribution in #1094
• @krsatyamthakur-droid made their first contribution in #1125
• @clubanderson made their first contribution in #1151

Full Changelog: v1.11.0...v1.12.0

Welcome to the v1.11.0 release of Kit! We've added some exciting new features and improvements.

New Features

LLM Prompt support in ModelKits

KitOps now supports storing prompt files (e.g. CLAUDE.md) in ModelKits as a distinct section within the Kitfile. This allows for unpacking and reading prompts in a ModelKit separately from the rest of the ModelKit data.

To get started, you can add a prompts section to your Kitfile:

manifestVersion: 1.0.0
package:
  name: prompt-kitfile
prompts:
  - path: CLAUDE.md
    description: "Additional instructions for Claude"

Support for prompts extends to the kit init command; if you run kit init in a directory that contains common agent instructions files (such as Claude.md) or files ending in .prompt, Kit should automatically detect those as prompt files in the generated Kitfile.

This change requires KitOps v1.11 to function; if you attempt to unpack a ModelKit containing prompts in an older version of Kit, it will fail.

For more information, see PRs #1034 and #1054

Self-signed certificates support for Kit commands

KitOps now supports the --tls-cert flag for all commands that communicate with a remote server. This allows Kit to verify remote self-signed or otherwise untrusted certificates without disabling TLS functionality entirely (e.g. via the --tls-verify=false or --plain-http flags). If you're running an internal registry with TLS enabled, Kit can now verify the certificate used by that server.

For more information, see PR #1058

Significant Changes

• Add Kubeflow Pipeline components for ModelKits by @gorkem in #1033
• Restrict matching for .bin files to pytorch_model from transformers by @amisevsk in #1059
• Automatically retry pushing chunks on HTTP errors by @amisevsk in #1073

Bug Fixes

• Fix kit login failure when trace logging is enabled by @akagami-harsh in #1070

New Contributors

• @akagami-harsh made their first contribution in #1070
• @Jaisheesh-2006 made their first contribution in #1077

Full Changelog: v1.10.0...v1.11.0

Welcome to the v1.10.0 release of Kit! With this release, we're proud to announce initial support for CNCF ModelPack artifacts in the Kit CLI.

New Features

CNCF ModelPack support

We've added support for the CNCF model-spec in the Kit CLI. For most use cases, this should mean that Kit is able to work with ModelPack artifacts in the same way it handles ModelKits, allowing you to push, pull, and unpack artifacts that conform to the ModelPack specification.

To create new ModelPack artifacts, the kit pack command now supports the --use-model-pack flag. If specified, instead of creating a ModelKit OCI artifact, Kit will create an OCI artifact in the model-spec format. Once created, these artifacts should be handled by the Kit CLI transparently, with no additional changes to usage, though additional tools that rely on ModelKit media types may have issues processing ModelPack artifacts.

For more detail, see the PR that added support: #1000

Documentation updates

• Adding Security page by @bmicklea in #1001
• Create INSTALL.md by @bmicklea in #1008

Bug Fixes

• Handle missing tag in ModelKit references per command by @amisevsk in #1003

Full Changelog: v1.9.0...v1.10.0

Welcome to the v1.9.0 release of Kit! We've added some exciting new features and improvements.

New Features

Untagging ModelKits in remote repositories

Prior to v1.9.0, using kit remove with the --remote flag would delete the remote ModelKit, removing both it and all tags that referred to it. With the changes in v1.9.0, removing remote ModelKits behaves more similarly to the local case:

• If the remove command has a digest (e.g. kit remove --remote registry.com/repository/modelkit@sha256:<digest>), the ModelKit with that digest is deleted from the remote repository, removing it and all tags referring to it
• If, however, the remove command uses a tag (e.g. kit remove --remote registry.com/repository/modelkit:latest), only the tag is removed; the ModelKit can still be pulled by digest or any additional tags pointing to it
  • To delete the ModelKit itself, you can use a tag and the --force flag, which will resolve the tag to a digest and then delete that digest.

For more details, see kit remove --help, or the PR: #978

Significant Changes

KitOps version check endpoint change

As of KitOps v1.9.0, the CLI will use https://kitops.ml/version to check for updates when running Kit commands. The benefits of this endpoint are twofold:

• It's generally faster to respond than the GitHub API we were using
• It will correctly list the latest full release, skipping draft releases and prerelease versions

With this change, Kit will now also send two pieces of additional information on version checks:

• A user-agent string matching what KitOps sends to registries (kitops-cli/<version>)
• An X-Command header containing the top-level Kit command used (e.g. push for kit push <destination>)

To disable automatic version checks, use the command below:

kit version --show-update-notifications=false

For more details, see the original PR: #979

New Contributors

• @gavrissh made their first contribution in #968

Full Changelog: v1.8.0...v1.9.0

Welcome to the v1.8.0 release of Kit! We've added some exciting new features and improvements.

New Features

SBOM generation for KitOps CLI releases

Thanks to @bupd, KitOps releases now include SBOM manifests in their release assets. You can find these assets published as part of the v1.8.0 release, and similar SBOMs will be included in new releases going forward.

For more details, see the PR by @bupd: #951

Support for using ModelKit references with kit dev

The kit dev command now supports supplying a ModelKit reference instead of using a local directory. This means that it's possible to start a LLM server (based on gguf-formatted model weights) without first unpacking a ModelKit. Try it out using

kit dev start jozu.ml/jozu/qwen2-7b:latest

For more information, see kit dev start --help or @gorkem's PR: #944

Dynamic shell completions

The Kit CLI now supports dynamic shell completions based on the ModelKits you have pulled locally. This means that in addition to autocompleting kit command names (e.g. "push" or "pull"), the CLI will suggest completions for ModelKits and their tags when using commands that require a ModelKit reference.

To add completions to your current terminal session, use one of the following commands, depending on your current shell

# bash
source <(kit completion bash)
# zsh
source <(kit completion zsh)
# powershell
kit completion powershell | Out-String | Invoke-Expression
# fish
kit completion fish | source

Completions should be supported for bash, zsh, fish, and powershell, though we haven't had a chance to thoroughly test all shell interpreters -- if you encounter issues with completions, please open an issue in this repository so that we can work on fixing it!

For more information, see the PR that added this feature: #963

Significant Changes

• The Kit CLI will now default to using the latest tag when one is not provided. This behaviour mirrors what other OCI CLI's, such as docker and podman do, and avoids potentially confusing error messages when missing a tag during a command. For more information, see the PR by @mohammedahmed18: #935

Bug Fixes & Documentation Improvements

• Overhaul the README by @bmicklea in #918
• Huge docs update by @bmicklea in #922
• Add KServe Google Artifact Registry instructions by @gorkem in #962

New Contributors

• @bupd made their first contribution in #951

Full Changelog: v1.7.0...v1.8.0

Welcome to the v1.7.0 release of Kit! We've added some exciting new features and improvements.

New Features

GKE support in KServe container

Thanks to @tmbochenski, the KitOps KServe container now natively supports authenticating with Google Artifact Registry on GKE clusters. For documentation on setting this up, see the README.md

For more information, see the PR by @tmbochenski: #907

Docker credential store fallback for Kit CLI

Thanks to @mohammedahmed18, the Kit CLI will now use Docker's credential store as a fallback for authenticating with registries when an entry in Kit's credential store is not available. This means that if you are logged in to a registry in Docker, you no longer need to log in in the Kit CLI.

For more details, see the PR by @mohammedahmed18: #910

Format flag for kit list command

The kit list command now supports the --format flag, allowing you to list ModelKits in JSON or Go-templated formats. This is useful for automation and tooling, which might prefer a machine-parseable output instead of the normal table that Kit prints by default.

You can now specify kit list --format=json to output the list as JSON, or use a template to print only the information you need. See kit list --help for more information.

For more details, see @gorkem's PR: #906

Bug Fixes

• Fix HF import to handle files that do not have Content-Length header by @amisevsk in #911

New Contributors

• @mohammedahmed18 made their first contribution in #910
• @tmbochenski made their first contribution in #907

Full Changelog: v1.6.1...v1.7.0

Welcome to the v1.6.1 release of Kit! This commit addresses a storage requirements issue when running Kit pack in an otherwise uninitialized system (e.g. in CI/CD pipelines)

Bug Fixes

In v1.6.0, we found that in some of our continuous intergration (CI) jobs that make use of the Kit CLI, we were seeing errors around running out of free disk space. As we carefully size storage space to ensure we can process ModelKits in CI, this pointed to a bug in how KitOps was handling initialization of its internal, on-disk storage. In particular, if local storage was not initialized, Kit was falling back to a copy (rather than rename) flow when saving blobs to its internal registry. This led to a higher peak storage requirement during pack and could, in some cases, cause CI jobs to fail due to lack of disk space.

For more information, see PR #901

Full Changelog: v1.6.0...v1.6.1