MLflow
chirashi.mlflow
A Docker Compose file for MLflow alone, generated from the catalog and checked by the safety inspector. No account needed.
Platform for tracking machine-learning experiments, logging parameters, metrics and artifacts per run, with a model registry holding versions, stage transitions and lineage back to the producing run.
MLflow records each training run as a set of parameters, metrics over time, tags and artifacts, grouped into experiments and comparable side by side, which turns which configuration produced this result into a query rather than a feat of memory. The registry takes a logged model, versions it, carries stage annotations and links every version back to the run and code that produced it. A packaging format describes a model with its dependencies and signature so it loads through the same call regardless of the framework it was trained in. The tracking server needs a backend store for metadata and a separate artifact store for files.
You know it worked when
- The tracking interface loads and lists experiments.
- A run logs parameters and metrics that appear in the interface.
- An artifact logged by that run downloads intact.
- A model registered from the run appears in the registry with a version number.
- That version loads through the tracking URI from a separate process.
Known sharp edges
- The default configuration writes to local files, and both metadata and artifacts must be moved to durable backends before any of it can be relied on.
- The artifact store path is resolved by the client as well as the server, so a path valid inside the container is frequently invalid where training actually runs.
- The tracking server has no authentication of its own, and anyone reaching it can read or delete experiments and registered models.
- Artifact volume grows quickly when model files are logged per run, and nothing expires automatically.