Why This Post Exists

Running MLflow experiments locally means losing access to centralized tracking and collaboration → Pointing your local notebook’s MLflow client at a Databricks workspace gives you remote experiment tracking without leaving your local environment.

The Problem

Data scientists often prototype models in local Jupyter notebooks but lose the benefits of centralized experiment tracking — versioned runs, shared metrics, and team-visible results — because MLflow defaults to logging locally. Switching to a Databricks notebook just for tracking adds friction and pulls engineers away from their preferred development setup.

The Solution

This playbook shows how to configure MLflow in a local notebook to use a Databricks workspace as its tracking server. With three lines of Python and an existing Databricks CLI profile, experiment runs logged locally appear in the Databricks Experiments tab, giving teams a single source of truth for all model development activity regardless of where the code runs.

Example Use Cases

Logging local notebook experiments to Databricks so the team can see them.
Switching MLflow tracking between multiple Databricks workspaces via CLI profiles.
Centralizing experiment data without forcing everyone into Databricks notebooks.

MLFlow Tips and Tricks #1

Using Databricks as an MLFlow repository from a local notebook

You can run MLFlow in a local notebook and use a Databricks workspace as your tracking server. Meaning, you will log to the Experiments tab in that workspace.

If you have the Databricks cli set up, you’re already configured. If not, start here: https://docs.databricks.com/aws/en/dev-tools/cli/tutorial

Run the following commands to set the tracking server to your DEFAULT Databricks CLI profile.

import mlflow
mlflow.login()
mlflow.set_tracking_uri("databricks")

Change the argument to set_tracking_uri to use a different profile, e.g. “MY_PROFILE”:

mlflow.set_tracking_uri("databricks://MY_PROFILE")