Why Git Is Not Enough
When a software bug appears in production, engineers check Git to see what code changed. But when an ML model starts making worse predictions, the cause is rarely just the code.
A model's behavior is determined by three things simultaneously:
1. The training code — the algorithm and architecture
2. The training data — the exact dataset snapshot used
3. The hyperparameters — learning rate, regularization strength, tree depth, etc.
Changing any one of these produces a different model binary. You can version the code in Git, but the resulting .pkl or .pt file — the artifact that actually runs in production — is a binary blob that Git handles poorly. And Git has no concept of linking a model file to the specific dataset version that produced it.
What a Model Registry Does
A Model Registry (MLflow Model Registry is the most widely used open-source option) is a centralized repository for storing, versioning, and managing trained model artifacts. Think of it as a combination of Git, a package registry, and a deployment pipeline — but for ML models.
It tracks:
- Artifact Storage: The actual model binary (
.pkl,.pt, ONNX file, etc.) stored in object storage (S3, GCS, Azure Blob). - Version History: Each training run that produces a model creates a new version. "Version 3 was trained on the January dataset. Version 4 used the February dataset with a new architecture."
- Lineage: Each version is linked to the exact Git commit, dataset snapshot identifier, and logged hyperparameters from the training run that produced it. This is critical for debugging and regulatory audits.
- Stage Transitions: Versions are tagged with lifecycle stages —
Staging,Production,Archived. Deployment automation watches for theProductiontag and automatically pulls the latest production-tagged model.
The Deployment Workflow with a Registry
This workflow makes deployments auditable, repeatable, and reversible. Rolling back is as simple as promoting the previous version back to Production.