MLflow is open source software for AI engineering, built around machine learning models, LLM applications and agents. It records your experiments (parameters, metrics, files), keeps versions of your models in a registry, evaluates them and handles deployment. You can use it on one laptop, across clusters or with a managed service.
What MLflow gives a machine learning project
- Experiment tracking. An API and a UI for logging parameters, code versions, metrics and output files whenever you run machine learning code.
- Model evaluation. Capabilities for checking how a model performs, sitting alongside the rest of the development work.
- A production model registry. One central home for your model versions.
- Deployment tools. The tooling for taking a model from development into deployment.
- Cover beyond classic ML. The platform is aimed at agents and LLMs as well as ML models.
- A choice of where it runs. Your local environment, on-premises clusters, cloud platforms or managed services, and it's vendor-neutral.
Put simply, it's the record-keeping and handover layer for model work: what you tried, what came out of it, which version is the good one and how that version gets out of development.
How a tracked training run plays out
The basic unit is the run. A run is one execution of your data science code, so a single python train.py execution counts as one. Change a setting, execute the script again, and you've got a second run you can hold up against the first.
Runs sit inside an experiment, which groups runs and models for one specific task. If you're working on a churn model and a recommendation model at the same time, those would be two experiments, each collecting its own runs. You can create an experiment from the command line, through the API or in the UI, so use whichever suits how you work.
Four kinds of information get logged. Parameters are the settings you chose before training. Metrics are the numbers that tell you how it went. Code versions tell you which code produced the result. Output files are whatever the run saved. With all four recorded against a run, the question 'which settings gave us that good result last month?' has an answer that doesn't depend on anyone's memory.
You don't have to write every logging line yourself. Call mlflow.autolog() before your training code and metrics, parameters and models are logged without explicit log statements. That's the low-effort way in, and it's why a first trial can be a small change to a script you've already got.
Once a model's worth keeping, the Model Registry takes over. It's the central place for versioning a model, managing the stage it's at and tracking its lineage, meaning where that version came from. Without something like that, 'the latest model' tends to mean whichever file someone saved most recently.
By default, your MLflow results stay on one machine
With no server or database set up, MLflow Tracking logs to a local mlruns directory. That's ideal for one person trying things out, and it stops working the moment a colleague wants to see your runs, because the records are sitting in a folder on your computer.
Sharing results with a team needs a remote database and storage. Decide early where shared runs will live, so you aren't comparing notes from several people's separate folders. For the exact setup, check the project's own documentation.
How to try MLflow on one script
- Install it using the instructions in the project's own documentation.
- Pick a training script you've already got, such as a
train.pyfile. - Add a call to
mlflow.autolog()before your training code. - Run the script once. That execution is your first run.
- Look in the local
mlrunsdirectory, where the logged data goes if you've set up no server or database. - Change one setting and run the script again, so you've got two runs to compare.
- Create an experiment through the CLI, API or UI once you want related runs grouped for one task.
Two runs is enough to see whether this helps you. The next decision is the one from the section above: stay on your own machine, or set up shared storage for the team.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Who MLflow suits, and who can skip it
It suits data scientists and developers who train models repeatedly and need a dependable record of what happened each time. If you've ever looked at a good result and been unable to say exactly what produced it, that's the problem this is for.
It's a stronger fit with more than one person on a project, because once you've set up shared storage, the registry gives everyone one central place for model versions. It also makes sense if you'd rather not commit to a single vendor, given that it can run anywhere from your own computer to a managed service. And if your work has moved on to LLM applications or agents, those are in scope too.
You can skip it if you aren't writing machine learning code at all. With no training runs, models, LLM applications or agents to manage, there's nothing for it to keep track of.
Frequently asked questions
Can I use it from R or Java?
Yes. Python isn't the only way in, because the Tracking component also offers R and Java APIs, plus a REST API.
Is a run the same thing as an experiment?
No. A run is a single execution of your code, while an experiment is the group that holds runs and models for one task.
Can MLflow run on my own servers?
Yes. On-premises clusters are one of the places it's supported.
Is MLflow tied to one cloud provider?
No. It's vendor-neutral, so you aren't committing to a single company's platform.
Is MLflow only for traditional machine learning?
No. It's built for LLM applications and agents as well as ML models.
