From Dev to Deploy: Why We Package AI/ML Artifacts with OCI, Not Git

In recent releases, both FluxCD and ArgoCD—two of the most widely used continuous deployment tools—have added support for deploying from OCI artifacts. At first glance, this might seem like a minor addition. But it signals something deeper: the growing recognition that development and deployment are fundamentally different phases of the lifecycle. And because of the inherent uncertainty and mutability of AI/ML artifacts, this separation is even more critical in AI systems.

Let’s unpack that.

🛠️ Git Is Great for Development

Tools like DVC, Hugging Face Hub, and Git LFS are excellent for development workflows. They’re optimized for:

• Rapid experimentation

• Versioning models alongside code

• Collaborative iteration between data scientists

These tools assume a development mindset: mutable history, active collaboration, and quick rollback. That’s perfect when you're training, tuning, and testing—but it starts to fall apart when you're preparing for production.

🚧 Git Breaks Down at Deployment

Once you're ready to serve models in production, your requirements change:

• You need immutability, not editable branches

• You need to promote the exact same artifact across dev, staging, and prod

• You care about provenance, signing, and attestations

• Your CI/CD system must treat models and datasets as first-class deployable units

Git wasn’t built for this. Teams often end up with brittle workflows: custom scripts, out-of-band state management, and inconsistencies that are hard to debug.

✅ OCI Artifacts Are Built for Deployment

Enter OCI artifacts—the same standard used to ship Docker containers. But OCI is broader than that. It’s a general-purpose packaging format that supports any binary blob, including model checkpoints, datasets, and structured metadata.

KitOps leverages OCI to package ModelKits: versioned, self-contained AI/ML artifacts with metadata, optional attestations, and digital signatures. This brings deployment maturity to model management:

• Immutable by digest

• Promotable via tag and digest separation

• Verifiable using Cosign, Notation, or Sigstore

• Integrates with policy engines like Kyverno and Gatekeeper

These aren’t theoretical advantages. OCI artifacts are hardened, production-grade units. With KitOps, those same principles apply to models and data pipelines.

🧩 Where Git Ends and KitOps Begins

Here’s how responsibilities divide across the ML lifecycle:

Some teams attempt to stretch Git + DVC all the way to production, but that often involves fragile CI logic, lockfile gymnastics, and deep institutional knowledge. OCI-native workflows avoid these traps by building on standard, cloud-native patterns.

This isn’t just a packaging debate—it’s about ecosystem fit. OCI artifacts integrate seamlessly into Kubernetes-centric environments. They can be signed, scanned, validated, and promoted using the same pipelines and tooling already adopted by DevOps and platform teams.

🧠 Final Thought

If you're deploying models by cloning Git repositories and running bash scripts, you're using dev tools to solve a deployment problem. That might work—until it doesn't.

Infrastructure teams already use OCI to ship software. KitOps brings that same discipline to AI/ML. With OCI-based ModelKits, you're not just deploying models—you're treating them like the production software they are.