Model Registry

What a model registry is

When an ML team has trained a dozen model versions, the question “which one is running in production right now?” sounds simple until nobody can answer it. Model files end up scattered across shared drives, S3 buckets, and local laptops. Metrics live in spreadsheets. Approvals exist only in Slack threads. A model registry solves this by giving every trained model a stable address, a version number, and a lifecycle state—all in one place.

Think of it as Git for trained models, extended to cover not just the artifact but its context: what training data was used, what evaluation scores it achieved, who approved it for production, and when. Unlike a plain file store, the registry understands that a model passes through stages—experimental, staging, production, archived—and records each transition with an audit trail. That history is what makes rollback possible in minutes rather than days.

In an MLOps workflow (machine learning operations—the set of practices for managing ML systems in production), the registry sits at the center. It connects upstream training systems with downstream serving infrastructure. This is what makes model versioning and artifact stores practical rather than theoretical: the registry is the organizational layer that records the metadata, tracks the lineage, and controls which version is active at any given moment. The article on versioning, metadata, and artifact stores explores these concepts at depth—the registry is where they converge in a working system.

How a model registry is used in practice

The most common way a product manager or team lead encounters a model registry is when their ML team says “we just pushed v2.3 to staging” or “we’re rolling back to the previous version.” What they’re describing is a state change in the registry.

In practice, the workflow looks like this: a model finishes training, the training script logs the run to an experiment tracker (recording loss curves, hyperparameters, etc.), and the best-performing version gets registered. The registry assigns it a version number, stores the artifact path, and sets its stage to “staging.” After evaluation in a staging environment, a human reviewer or an automated gate promotes it to “production.” That promotion is recorded alongside who approved it and when. When something goes wrong, the rollback is a state change—point the registry back to the prior production version, and serving infrastructure follows.

Use the registry’s tagging system to attach the training dataset version alongside the model version. When a production incident surfaces six months later, knowing which data vintage the model saw is often the fastest path to root cause—especially when the issue turns out to be a data quality problem, not a model problem.

Reading the model registry stack in the right order

Start with what a model registry actually stores and how MLOps artifact stores work — it lays out the pieces every other article here assumes you already recognize: artifact storage, metadata, staging environments, approval workflows. Read version sprawl, schema drift, and the engineering limits of a registry at enterprise scale next — the companion piece: a registry tells you which version exists, not whether that version still matches what your code sends it, and the gap only shows up once hundreds of models cross multiple teams.

Once the concepts hold, setting up a registry with MLflow and DVC is the build guide — aliases instead of deprecated stages, rollback as an alias reassignment rather than a redeploy. If you’re choosing a tool rather than following one recipe, the MLflow vs W&B vs SageMaker vs DVC comparison narrows the decision to two variables: team size and cloud commitment. For where the category is heading, the 2026 shift toward LLM weight management and multi-cloud catalogs explains why classical registries are splitting from LLM-native ones. Close with the accountability gap in automated model promotion — the governance question a registry’s audit trail cannot answer by itself.

Where a model registry is confused with its neighbours

Registry vs. experiment tracking. Experiment tracking records what happened during training — parameters, metrics, which run produced which weights. The registry is the downstream system of record: it takes one of those runs and gives it a stable, deployable identity with staging and approval workflow attached. Skipping straight to a registry without experiment tracking upstream leaves you registering artifacts you can’t explain.

Registry vs. model routing. These answer different questions at different times. The registry decides which artifact version is authorized to exist and be promoted; routing decides which model answers this particular request, right now, by cost or latency. A registry with perfect version control still needs a routing layer in front of it — the two are sequential, not substitutable.

Classical registry vs. LLM-native weight manager. A registry built for scikit-learn-era pickle files and small parameter sets assumes artifacts you can diff and store cheaply. LLM weights run to gigabytes or terabytes, span multiple clouds, and need OCI-compliant storage the old Staging → Production model was never built to hold — which is why the category is actively splitting rather than just adding features.

When a model registry fits — and when it doesn't

Common questions about the model registry

Q: Do small ML teams need a dedicated model registry, or does a versioned folder of files cover it? A: A folder holds until more than one person deploys, or someone asks which version served last month’s predictions — at that point the coordination problem is exactly what version sprawl at enterprise scale describes, just starting smaller. Team size and cloud commitment decide when the switch is worth it.

Q: Should model promotion be triggered by a registry webhook or by a CI/CD git tag? A: Pick one trigger per environment and document it — mixing an MLflow webhook with a DVC git tag creates a race where either mechanism can promote a model independently, and nobody can say which one actually fired. The MLflow-and-DVC setup guide validates each trigger layer separately before wiring them together.

Q: Does a registry’s audit trail prove a model deployment was properly reviewed? A: No — the audit trail records what was deployed and when, not whether a human judged it fit to ship. An automated pipeline can clear every evaluation threshold and promote a model with no named person signing off, which is the governance gap automated model promotion examines.

Q: Will my existing model registry work once I start deploying LLMs instead of scikit-learn models? A: Probably not without changes — classical registries assume small, diffable artifacts, while LLM weights run to terabytes across multiple clouds. The 2026 shift toward LLM weight management covers the OCI-compliant storage and alias-based promotion now displacing the old model.

Part of the LLMOps stack · closest neighbour: model routing.