9 · Model registry & DagsHub
Tracking tells you which run was best; the model registry is what promotes it to production. Register a model, move it through stages — None → Staging → Production — and load it by stage, so serving never hard-codes a run ID.
The MLflow model registry is a versioned catalog ON TOP of tracking: you REGISTER a run's model under a name, each registration is a new VERSION, and you transition versions through STAGES (None → Staging → Production → Archived). Serving loads the model by NAME and STAGE (`models:/churn/Production`) — so promoting a new model is a stage transition, not a redeploy with a hard-coded run ID.
Without this:
Without a registry, 'the production model' is an informal pointer — a run ID pasted into a config, a filename on a server. Promoting a new model means hunting that reference down and redeploying, with no audit trail of which version was live when.
Tracking (lesson 8) answers "which run was best?". But knowing the best run isn't the same as shipping it. You need a controlled way to say "this model version is now the one production serves" — and to change that decision safely as better models arrive. That's the model registry.
The registry sits on top of tracking and adds three ideas:
1. Registered models (by name). You give a model a stable name — churn-classifier — independent of any single run. Serving code refers to that name, not to a run ID buried in a notebook.
2. Versions. Every time you register a model under that name, you get a new version (v1, v2, v3, ...). MLflow keeps them all. Version 7 might be live while version 8 is being evaluated — both exist in the registry.
3. Stages. Each version sits in a stage, and you transition it between stages:
- None — just registered, not yet assigned anywhere.
- Staging — a candidate under evaluation (running shadow traffic, A/B tests, final checks).
- Production — the version actually serving live traffic.
- Archived — retired, kept for audit/rollback.
The promotion flow is None → Staging → Production, and when a new version is promoted to Production, the old one is typically moved to Archived (or kept as a rollback target). You do this with MlflowClient().transition_model_version_stage(name, version, stage).
The payoff is in loading. Serving code loads the model by name and stage: mlflow.pyfunc.load_model("models:/churn-classifier/Production"). It never names a version number or run ID. So when you promote v8 to Production, every service that loads .../Production picks up the new model on its next load — no code change, no redeploy with a hard-coded ID, full audit trail of which version was Production when.
DagsHub is a hosted home for all of this. It gives you a free, managed MLflow tracking server (so your runs and registry live in the cloud, not just on your laptop) and a DVC remote (lesson 10) for your data — plus Git, in one place. You point MLflow at it by setting the tracking URI to your DagsHub repo and authenticating with a token. The same mlflow.log_* and registry calls then write to the cloud instead of a local folder.
MLflow servers and DagsHub aren't browser-runnable, so the code below is read-along — the shape (register → transition → load by stage) is the takeaway.
Register a run's model under a name (creating a version), transition it None → Staging → Production with `MlflowClient`, then load it by stage with `models:/churn-classifier/Production`.
Set `MLFLOW_TRACKING_URI` (and credentials) to a DagsHub repo so runs and the registry live in the cloud, and add DagsHub as a DVC remote — tracking, data versioning, and Git in one place.
In the MLflow model registry, what is the standard promotion flow for a model version?
- The model registry sits on top of tracking: you register a run's model under a stable NAME, each registration is a new VERSION, and each version sits in a STAGE.
- Promote a version forward None → Staging → Production with `transition_model_version_stage`, archiving the old Production version; serving loads by stage (`models:/name/Production`), never by run ID.
- DagsHub provides a hosted MLflow tracking server AND a DVC remote (plus Git) in one repo — set `MLFLOW_TRACKING_URI` to it and the same logging/registry calls write to the cloud.
Production ML platforms gate releases through a registry: a model is promoted to Production only after passing Staging checks, and serving always loads the stage, giving instant rollback and a full audit trail.
If you remove it: 'The production model' would be an informal, hard-coded reference, so promoting or rolling back a model means editing configs and redeploying — error-prone and with no record of what was live when.