KitOps: Package AI/ML Models Into Versioned OCI Artifacts for Your Registry

You've probably pushed a Docker image to a registry. You know the drill: tag, push, pull, deploy. But what about your AI/ML models? Your trained weights, tokenizers, config files, and training data? Right now, most teams stash them in S3 buckets, random Git LFS repos, or worse—shared drives. That's messy, unversioned, and hard to audit.

KitOps fixes that. It lets you package an entire ML project into an OCI-compliant artifact (think Docker image, but for ML). You push it to any standard container registry (Docker Hub, GHCR, ECR, etc.), version it, and share it with your team. No more "which model.bin is the latest?" headaches.

What It Does

KitOps takes your ML project's components—model weights, tokenizers, training configs, datasets, and metadata—and bundles them into a single versioned OCI artifact called a "Kitfile." That artifact lives in your registry alongside your container images. You can tag it, sign it, and pull it just like you would with docker pull.

The core command is kit pack and kit unpack. You point it at your project directory, define what's important in a Kitfile (similar to a Dockerfile), and it builds the artifact. Later, any teammate (or CI/CD pipeline) can kit unpack that artifact to recreate the exact ML environment.

Why It’s Cool

Here's what makes KitOps stand out:

• Versioned, auditable artifacts. Every time you pack a model, you get a digest. Tag it with latest or v2.1.0. Roll back instantly. No more "train the model, copy the files, hope nobody overwrites them."
• Works with any OCI registry. You already use Docker Hub or ECR? Great. KitOps pushes to those same registries. No new infrastructure needed.
• Stackable components. Your Kitfile can reference base images, dependencies, and even other KitOps artifacts. This is perfect for teams that iterate models frequently but need reproducibility.
• CLI-first, developer friendly. It's a small binary. No Python runtime requirement, no heavy SDK. kit pack and kit unpack are all you need.
• Model agnostic. Doesn't care if you're using PyTorch, TensorFlow, ONNX, or a custom binary. It just packages whatever you define.

Use cases? CI/CD for ML models—build, test, pack, push. Or share a model with a teammate in two commands. Or archive a specific training run for compliance.

How to Try It

The easiest way is to grab the CLI from the GitHub releases. There's a prebuilt binary for Linux, macOS, and Windows.

# Download the binary (example for Linux x86_64)
curl -L https://github.com/kitops-ml/kitops/releases/latest/download/kit-linux-amd64 -o kit
chmod +x kit
sudo mv kit /usr/local/bin/

# Create a simple Kitfile for your AI project
cat > Kitfile <<EOF
model:
  path: model.onnx
configs:
  - path: tokenizer.json
EOF

# Pack it into an OCI artifact
kit pack . -t my-registry.com/ml-project:latest

# Push to your registry (e.g., Docker Hub)
kit push my-registry.com/ml-project:latest

# On another machine, pull and unpack
kit pull my-registry.com/ml-project:latest
kit unpack my-registry.com/ml-project:latest

That's it. You now have a versioned ML artifact in your registry. Check the README for advanced usage like signing, multi-component artifacts, and integration with existing CI.

Final Thoughts

KitOps isn't trying to be a full ML platform. It's a focused tool that solves a specific, painful problem: how do you share and version ML projects in a way that doesn't feel like duct tape? By using the same OCI standard that Docker popularized, it fits into your existing workflow with minimal friction.

If you've ever spent 30 minutes hunting for the right model file, or argued with a teammate about which S3 bucket has the production weights, give KitOps a shot. It's one of those tools that feels obvious once you see it—like "why didn't we do this before?"

Follow us on X: @githubprojects