Practice: Model registry, packaging and versioning
Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.
Main tool: Model registry · The open source MLflow Model Registry runs entirely on a laptop and exposes every idea in this lesson (named models, immutable versions, lineage to a run, aliases, tags and a standard package format) through one UI and one API. · Alternatives: SageMaker Model Registry is a managed cloud registry built around model package groups and approval status, Unity Catalog adds three-level names and central access governance across workspaces, and a plain object store with container image tags is the do-it-yourself option with no lineage or aliases.
Every step links into the tool's own documentation; links were checked on 2026-10-11 · version 1
Setup (one time)
1. Install MLflow and the tutorial's training library into a fresh Python virtual environment.
A clean environment keeps the versions recorded inside each packaged model honest. The registry ships inside the MLflow package, so there is nothing else to install.
Explained in: Model Registry Tutorials | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: The mlflow command prints a version number in your terminal.
2. Start a local MLflow tracking server and point your shell's tracking URI at it.
The registry needs a server-backed store to hold registered models and versions. Using a server from the start matches how a team works.
Explained in: Model Registry Tutorials | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: The MLflow UI opens in your browser on the local port and shows an empty Models page.
3. Install a local container runtime such as Docker and confirm it can build images.
A later step packages a registered model version as a serving image. This needs no cloud account and no GPU.
Explained in: ML Serving Docker Image | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: The container runtime reports that it is running and can list local images.
Steps
1. Run the tutorial script that trains a small model and registers it under a name.
This is the shortest path from a trained object to a registry entry. It shows that registration is one extra argument at logging time.
Explained in: Model Registry Tutorials | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: The Models page of the UI lists your model name with Version 1.
2. Read the registry concepts and match each one to what you see in the UI for your model.
Registered model, model version, alias, tag and description are the whole object model. Knowing what the registry stores, and that it stores references and metadata, explains every later step.
Explained in: ML Model Registry | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: You can point at the registered model, its version, its source run and its empty alias and tag fields in the UI.
3. Create a model logged with a signature and an input example, then open its MLmodel file and the files stored beside it.
The MLmodel file is what makes the artifact self-describing: flavors, signature, and environment files travel with the weights. A serving stack reads this file instead of asking how the model was trained.
Explained in: ML Models | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: You can name the flavors, the signature and the dependency files listed in the artifact directory.
4. Register a second version of the same model from a new training run with different parameters.
Versions are immutable and increment automatically, and each one links back to the run that produced it. That link is the lineage a release depends on.
Explained in: Model Registry Workflows | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: The model shows Version 1 and Version 2, each linking to a different source run with different metrics.
5. Query the registry through the client API to list registered models and search the versions of your model.
Pipelines talk to the registry by API, not by clicking. Searching versions is how you compare candidates and audit what exists.
Explained in: Model Registry Workflows | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: A script prints both versions with their version numbers, run ids and source locations.
6. Configure a champion alias on one version and a challenger alias on the other, and add a validation status tag to each.
Aliases are movable pointers that say which version may be deployed, while tags record facts about a version. Together they replace the deprecated stage field.
Explained in: Model Registry Workflows | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: The UI shows each alias on its version, and reassigning the champion alias moves it without creating a new version.
7. Load the model once by name and version number and once by alias, then move the alias and load both again.
A version reference is an immutable pin that always returns the same artifact. An alias reference follows whatever was promoted, so you choose which one a release should record.
Explained in: Model Registry Tutorials | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: The version reference returns the same model before and after the move, while the alias reference returns the other one.
8. Create separate registered models for a dev and a prod environment and promote a version from one to the other by copying it.
Promotion between environments is a copy of an already validated version, not a retrain. The copy keeps its link to the source version so lineage survives.
Explained in: Model Registry Workflows | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: The prod registered model contains a version whose details point back to the dev version it was copied from.
9. Serve the promoted version locally from its registry reference and send it the saved input example.
Serving from a registry reference proves the package is enough to run the model. No training code or copied file is involved.
Explained in: Model Registry Workflows | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: A request to the local scoring endpoint returns predictions for the input example.
10. Package the same model version as a serving container image and run it with your local container runtime.
An image built from a fixed version reference, and later referenced by its digest, pins both model and runtime immutably. This is the unit a deployment system actually ships.
Explained in: ML Serving Docker Image | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: The running container answers a scoring request with the same predictions as the local server.
11. Reproduce the model's environment in a clean virtual environment from the dependency files stored in the package, then load and score it there.
Pinned dependencies recorded with the artifact are what let CI or another machine rebuild the same runtime. A package that only works on the training laptop is not a release.
Explained in: ML Models | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: The model loads and scores in the new environment with no manually added packages.
12. Configure the tracking server with a database backend store and a separate artifact store, then register and load a version through it. A cloud bucket would normally hold artifacts, so use a local database and a local object store container as the substitute.
Production registries separate metadata from artifacts so both can be backed up, shared and access controlled. Running this layout locally shows where versions and files really live.
Explained in: ML Experiment Tracking | MLflow AI Platform (mlflow.org), checked 2026-10-11
Done when: A new version appears in the UI, its metadata is in the database, and its files are in the artifact store.