KitOps Documentation
repository·main·Indexed 23 days ago
https://github.com/kitops-ml/kitopsKitOps is a CNCF open-source tool for packaging, versioning, and securely sharing AI/ML projects using OCI-compliant ModelKits. It enables teams to treat AI assets like container images for standardized deployment, security scanning, and lifecycle management. The project includes the Kit CLI for managing ModelKits, the PyKitOps Python SDK for programmatic integration, and support for cryptographic signatures via Cosign and AI Bill of Materials (AI SBOM) for compliance.
What's inside KitOps
- KitOps is an open-source standard for packaging, versioning, and sharing AI projects. It bundles models, datasets, code, prompts, agent skill files, MCP server configurations, and documentation into a single versioned OCI (Open Container Initiative) artifact. These artifacts are stored in your existing container registry, allowing you to manage AI assets just like container images.
Overview of the PyKitOps Python library
mainPyKitOps is a Python SDK designed to allow developers to interact with KitOps ModelKits directly within Python-based AI workflows. It provides programmatic access to the KitOps ecosystem, enabling the management, versioning, and handling of ML models and associated metadata through code.Use KitOps with MLOps, Serving, and Pipeline tools
mainBecause KitOps follows OCI standards, it is compatible with a wide range of tools across the ML lifecycle.
MLOps Tools
KitOps works with major platforms for model tracking, experimentation, and orchestration, including:
- Amazon SageMaker, Azure ML, Google Vertex, Databricks, MLFlow, Weights & Biases, Hugging Face, Kubeflow, and more.
Serving Platforms
Any platform that accepts containers can serve KitOps ModelKits, such as:
- Kubernetes (EKS, AKS, GKE), Kserve, Red Hat OpenShift, Amazon Fargate, and Amazon Lambda.
Pipeline & Storage Tools
KitOps integrates with standard CI/CD and storage tools:
- CI/CD: GitHub Actions, GitLab Pipelines, Jenkins, Circle CI, Argo CD, and Tekton.
- Storage/Version Control: Amazon S3, Git, and Git LFS.
What is a ModelKit?
mainA ModelKit is a self-contained, immutable, and versioned bundle used to package AI/ML projects. It is built on OCI (Open Container Initiative) technology, allowing it to be stored and retrieved from any standard container registry.
A ModelKit can include:
- Model weights
- Datasets
- Agents and MCP servers
- Prompts and metadata
- Environment configurations and code
- Experiment run results and hyperparameters
Key Properties:
- Tamper-proof: Every component is protected by SHA-256 digests.
- Signable: Fully compatible with Cosign for cryptographic verification.
- Compatible: Natively works with all major OCI container registries.
- Selectively unpacked: You can pull only specific layers (e.g., just the model weights) without downloading the entire bundle.
What is a Kitfile?
mainA Kitfile is a YAML-based manifest that serves as the blueprint for an AI project packaged as a ModelKit in KitOps. It defines the components of your project—such as models, datasets, code, prompts, and documentation—allowing you to package, version, and deploy them via any OCI-compatible registry.
Key benefits include:
- Full traceability for models, agents, or combined projects.
- Reproducibility across different environments.
- Seamless collaboration between ML, DevOps, and AI engineers.
- Integration with CI/CD pipelines.
What is ModelKit?
mainModelKit is a standardized, OCI-compliant packaging format designed for AI projects. It bundles various AI project artifacts—such as models, datasets, code, prompts, agent skill files, MCP server configurations, and documentation—into a single, versioned, and shareable artifact.
Key characteristics include:
- OCI-compliant: ModelKits can be stored, tagged, and versioned in any standard container registry (e.g., DockerHub, GitHub Packages, or private registries) using familiar DevOps tools.
- Selective Unpacking: You can unpack specific parts of a kit (e.g., only prompts or only model weights) to optimize pipelines.
- Asset Reuse: Supports reusing shared assets like datasets or configs across multiple kits without duplicating storage.
- Versatile Content: Handles both large binary files (model weights) and small text files (prompts, configs) within the same artifact.
Understand the ModelKit structure and components
mainA ModelKit is a comprehensive bundle of AI/ML artifacts (models, datasets, code, and parameters). It is composed of three primary elements:
- Artifacts: The modular building blocks of the kit. Each artifact is stored and addressed individually. Supported media types include:
- Serialized Model:
application/vnd.kitops.modelkit.model.v1.tar - Additional Model files (e.g. adaptors):
application/vnd.kitops.modelkit.modelpart.v1.tar - Datasets:
application/vnd.kitops.modelkit.dataset.v1.tar - Code:
application/vnd.kitops.modelkit.code.v1.tar - Docs:
application/vnd.kitops.modelkit.docs.v1.tar
- Serialized Model:
- Kitfile: A central record (using
application/vnd.kitops.modelkit.config.v1+json) that details the properties, relationships, and intended uses of the included artifacts. - ModelKit Manifest: An immutable JSON document following the OCI Image Manifest Specification. It contains metadata like creation date, authorship, and cryptographic hashes of all artifacts and the Kitfile to ensure integrity.
- Artifacts: The modular building blocks of the kit. Each artifact is stored and addressed individually. Supported media types include:
Verify ModelKit signatures in Kubernetes
mainThe Kit init container supports Sigstore [Cosign] verification to ensure ModelKit integrity. You can use either local keys or keyless OIDC verification.
Option A: Local Cosign Key
- Store your Cosign public key in a Kubernetes Secret.
- Mount the Secret as a volume in the
initContainer. - Set the
COSIGN_KEYenvironment variable to the path where the key is mounted.
Option B: Keyless OIDC Verification
Set the following environment variables in the
initContainer:COSIGN_CERT_IDENTITY: The expected identity.COSIGN_CERT_OIDC_ISSUER: The OIDC issuer URL.
Identify and name ModelKits using IDs, Tags, and Repositories
mainModelKits are managed using a hierarchical naming system:
- ModelKitID: A unique identifier derived from the SHA256 hash of the manifest (e.g.,
sha256:a9561eb1b190625c9adb5a9513e72c4dedafc1cb2d4c5236c9a6957ec7dfd5a9). - Tag: A user-friendly descriptive name mapped to a
ModelKitID.- Allowed characters:
[a-zA-Z0-9_.-] - Constraints: Cannot start with
.or-; maximum length of 128 characters.
- Allowed characters:
- Repository: A collection of tags grouped under a common prefix.
- Format:
repository:tag(e.g., inmyllm:3.1.4,myllmis the repository). - Structure: Slash-separated name components, optionally prefixed by a DNS hostname (which may include an optional port like
:8080). - Name Component Rules: May contain lowercase characters, digits, and separators (period
., one or two underscores__, or one or more dashes-). Components cannot start or end with a separator.
- Format:
- ModelKitID: A unique identifier derived from the SHA256 hash of the manifest (e.g.,
Cancel KitOps operations with timeouts or signals
mainEvery KitOps function returns a
CancellablePromise. You can call.cancel()to terminate the underlying process. This is useful for:- Timeouts: Imposing a deadline on long-running operations like
pushorpull. - User Signals: Wiring cancellation to signals like
SIGINTfor graceful interruption.
When cancelled, the promise rejects with an
AbortError(specifically aDOMExceptionwithname: 'AbortError').import { push } from '@kitops/kitops-ts'; async function pushWithTimeout(ref, timeoutMs) { const op = push(ref); const timer = setTimeout(() => op.cancel(), timeoutMs); try { await op; } catch (err) { if (err instanceof DOMException && err.name === 'AbortError') { console.error(`Push timed out after ${timeoutMs}ms`); process.exit(1); } throw err; } finally { clearTimeout(timer); } } await pushWithTimeout('registry.example.com/org/my-model:v1.0.0', 5 * 60 * 1000);import { pull } from '@kitops/kitops-ts'; const op = pull('registry.example.com/org/my-model:v1.0.0'); process.once('SIGINT', () => { console.log('\nInterrupted — cancelling pull…'); op.cancel(); }); try { await op; console.log('Pull complete.'); } catch (err) { if (err instanceof DOMException && err.name === 'AbortError') { console.log('Pull cancelled.'); process.exit(130); // standard exit code for SIGINT } throw err; }- Timeouts: Imposing a deadline on long-running operations like
Understand OCI Manifest types for ModelKits
mainWhen using the
inspect()method, KitOps returns an OCI image manifest. TheManifestobject contains theschemaVersion,mediaType, and anartifactType. Theconfigfield holds the Kitfile descriptor, while thelayersarray contains descriptors for each content layer. Metadata can be attached viaannotations.interface Manifest { schemaVersion: number; mediaType: string; artifactType?: string; config: ManifestDescriptor; layers: ManifestDescriptor[]; annotations: ManifestAnnotations; }Use FilterFlag to select specific layers or paths
mainA
FilterFlagis a string expression used byunpackandinfocommands to target specific content within a ModelKit.Accepted Formats:
'model': Selects the entire model layer.'datasets:training': Selects a named dataset (e.g.,datasets:training).'docs:./README.md': Selects a specific file within a layer (e.g.,docs:./README.md).'model,datasets:validation': Selects multiple layers using comma-separated values.
type FilterFlag = string