How it differs from MLflow
Where MLflow alone falls short, and the layer Geo-MLOps adds on top of it
Geo-MLOps does not replace MLflow. It keeps MLflow inside, unchanged, and adds the layer that running models in production needs on top of it. This page puts the two setups side by side to show what was added.
Why MLflow
Tracking experiments and managing models by hand hits its limits quickly.
- Nothing is reproducible. Environments are scattered across personal machines, so it is hard to trace which data and parameters a run used.
- Manual bookkeeping. Versions and scores end up compared in spreadsheets and file names.
- Deployment and monitoring are disconnected. Training and deployment are manual, and there is no way to notice when performance drops after release.
So the whole process, from experiment tracking to monitoring, needs one consistent way of working, and MLflow was chosen as its foundation.
| Reason | Details |
|---|---|
| De facto industry standard | Open source that provides experiment tracking and a model registry together |
| Easy to adopt | A standard Python API: a few lines added to training code |
| Framework-neutral | Logs PyTorch, YOLO, scikit-learn and others the same way |
| Proven storage | Runs on widely used stores such as PostgreSQL and S3 |
A setup with MLflow alone
In a standard MLflow setup, clients log experiments and register models through the tracking server.
- Users: ML developers work through the Python client (
log_params,log_metrics,log_artifact,register_model), the CLI or a web browser. - Service: a single MLflow Tracking Server handles experiment tracking, the model registry, the artifact service and the web UI.
- Storage: metadata such as experiments, runs and model versions goes to PostgreSQL; large files such as model weights, images and logs go to S3-compatible storage.
The default setup has no authentication and no isolation between teams. Anyone who knows the address can see and change every experiment and model.
Where MLflow alone falls short
| Gap | What goes wrong |
|---|---|
| Security | With no authentication, models and experiment data are exposed |
| Governance | There is no approval step for putting a model into production, and no audit trail of who did what |
| Operations | MLflow does not deploy, serve, monitor (detect drift) or retrain (CT) |
The layer Geo-MLOps adds
Geo-MLOps leaves the MLflow core as it is and puts a platform layer in front of it, adding multi-tenancy, approval, deployment and observability.
The red dashed box in the diagram is what was added. The MLflow Tracking Server is reachable only through the platform gate and is never exposed directly.
| Added | What it does | More |
|---|---|---|
| MLflow gate | Checks the caller by tenant token and gives each tenant its own MLflow workspace. Developers keep using standard MLflow code | Use MLflow from a notebook |
| Role-based access | Five roles (VIEWER, DEVELOPER, OPERATOR, APPROVER, ADMIN), an approval workflow and an audit log | Roles and permissions |
| Operations automation | Edge deployment and rollback, monitoring, alerts, drift watch and retraining | What Geo-MLOps does |
| One UI | From experiments to deployment and monitoring, in one place | User guide |
At a glance
| MLflow alone | Geo-MLOps | |
|---|---|---|
| Experiment tracking and model registry | ✅ | ✅ (the bundled MLflow, unchanged) |
| Login and authentication | None | Login (JWT); MLflow uses tenant tokens |
| Team (tenant) isolation | None | A workspace and a Kubernetes namespace per tenant |
| Permissions | None | Five roles, eleven permissions |
| Promotion to Production | Anyone, immediately | Always through an approval request; safety-critical models need two approvals |
| Audit trail | None | Who did what is recorded and can be exported as CSV |
| Running training | By hand | Submitted from the wizard and run as a Kubernetes Job on the cluster |
| Serving and edge deployment | By hand | API services, deployment to field devices, rollback |
| Monitoring | None | Monitoring, alerts, drift (PSI, KS) |