Command-Line Interface
The MLflow command-line interface (CLI) provides a simple interface to various functionality in MLflow. You can use the CLI to run projects, start the tracking UI, create and list experiments, download run artifacts, serve MLflow Python Function and scikit-learn models, and serve models on Microsoft Azure Machine Learning and Amazon SageMaker.
Each individual command has a detailed help screen accessible via mlflow command_name --help.
mlflow
mlflow [OPTIONS] COMMAND [ARGS]...
Options
artifacts
Upload, list, and download artifacts from an MLflow artifact repository.
To manage artifacts for a run associated with a tracking server, set the MLFLOW_TRACKING_URI environment variable to the URL of the desired server.
mlflow artifacts [OPTIONS] COMMAND [ARGS]...
download
Download an artifact file or directory to a local directory. The output is the name of the file or directory on the local disk.
Either --run-id or --artifact-uri must be provided.
mlflow artifacts download [OPTIONS]
Options
list
Return all the artifacts directly under run’s root artifact directory, or a sub-directory. The output is a JSON-formatted list.
mlflow artifacts list [OPTIONS]
Options
log-artifact
Log a local file as an artifact of a run, optionally within a run-specific artifact path. Run artifacts can be organized into directories, so you can place the artifact in a directory this way.
mlflow artifacts log-artifact [OPTIONS]
Options
azureml
Serve models on Azure ML. These commands require that MLflow be installed with Python 3.
To serve a model associated with a run on a tracking server, set the MLFLOW_TRACKING_URI environment variable to the URL of the desired server.
mlflow azureml [OPTIONS] COMMAND [ARGS]...
build-image
Note
Experimental: This method may change or be removed in a future release without warning.
Register an MLflow model with Azure ML and build an Azure ML ContainerImage for deployment. The resulting image can be deployed as a web service to Azure Container Instances (ACI) or Azure Kubernetes Service (AKS).
The resulting Azure ML ContainerImage will contain a webserver that processes model queries. For information about the input data formats accepted by this webserver, see the following documentation: https://www.mlflow.org/docs/latest/models.html#azureml-deployment.
mlflow azureml build-image [OPTIONS]
Options
-
-m,--model-uri<model_uri> URI to the model. A local path, a ‘runs:/’ URI, or a remote storage URI (e.g., an ‘s3://’ URI). For more information about supported remote URIs for model artifacts, see https://mlflow.org/docs/latest/tracking.html#artifact-stores [required]
-
-w,--workspace-name<workspace_name> The name of the Azure Workspace in which to build the image. [required]
-
-s,--subscription-id<subscription_id> The subscription id associated with the Azure Workspace in which to build the image
-
-i,--image-name<image_name> The name to assign the Azure Container Image that is created. If unspecified, a unique image name will be generated.
-
-n,--model-name<model_name> The name to assign the Azure Model that is created. If unspecified, a unique image name will be generated.
-
-d,--description<description> A string description to associate with the Azure Container Image and the Azure Model that are created.
-
-t,--tags<tags> A collection of tags, represented as a JSON-formatted dictionary of string key-value pairs, to associate with the Azure Container Image and the Azure Model that are created. These tags are added to a set of default tags that include the model path, the model run id (if specified), and more.
db
Commands for managing an MLflow tracking database.
mlflow db [OPTIONS] COMMAND [ARGS]...
upgrade
Upgrade the schema of an MLflow tracking database to the latest supported version.
IMPORTANT: Schema migrations can be slow and are not guaranteed to be transactional - always take a backup of your database before running migrations. The migrations README, which is located at https://github.com/mlflow/mlflow/blob/master/mlflow/store/db_migrations/README.md, describes large migrations and includes information about how to estimate their performance and recover from failures.
mlflow db upgrade [OPTIONS] URL
Arguments
experiments
Manage experiments. To manage experiments associated with a tracking server, set the MLFLOW_TRACKING_URI environment variable to the URL of the desired server.
mlflow experiments [OPTIONS] COMMAND [ARGS]...
create
Create an experiment.
All artifacts generated by runs related to this experiment will be stored under artifact location, organized under specific run_id sub-directories.
Implementation of experiment and metadata store is dependent on backend storage. FileStore
creates a folder for each experiment ID and stores metadata in meta.yaml. Runs are stored
as subfolders.
mlflow experiments create [OPTIONS]
Options
-
-l,--artifact-location<artifact_location> Base location for runs to store artifact results. Artifacts will be stored at $artifact_location/$run_id/artifacts. See https://mlflow.org/docs/latest/tracking.html#where-runs-are-recorded for more info on the properties of artifact location. If no location is provided, the tracking server will pick a default.
delete
Mark an active experiment for deletion. This also applies to experiment’s metadata, runs and
associated data, and artifacts if they are store in default location. Use list command to
view artifact location. Command will throw an error if experiment is not found or already
marked for deletion.
Experiments marked for deletion can be restored using restore command, unless they are
permanently deleted.
Specific implementation of deletion is dependent on backend stores. FileStore moves
experiments marked for deletion under a .trash folder under the main folder used to
instantiate FileStore. Experiments marked for deletion can be permanently deleted by
clearing the .trash folder. It is recommended to use a cron job or an alternate
workflow mechanism to clear .trash folder.
mlflow experiments delete [OPTIONS]
Options
list
List all experiments in the configured tracking server.
mlflow experiments list [OPTIONS]
Options
rename
Renames an active experiment. Returns an error if the experiment is inactive.
mlflow experiments rename [OPTIONS]
Options
gc
Note
Experimental: This method may change or be removed in a future release without warning.
Permanently delete runs in the deleted lifecycle stage from the specified backend store. This command deletes all artifacts and metadata associated with the specified runs.
mlflow gc [OPTIONS]
Options
-
--backend-store-uri<backend_store_uri> URI of the backend store from which to delete runs. Acceptable URIs are SQLAlchemy-compatible database connection strings (e.g. ‘sqlite:///path/to/file.db’) or local filesystem URIs (e.g. ‘file:///absolute/path/to/directory’). By default, data will be deleted from the ./mlruns directory.
models
Deploy MLflow models locally.
To deploy a model associated with a run on a tracking server, set the MLFLOW_TRACKING_URI environment variable to the URL of the desired server.
mlflow models [OPTIONS] COMMAND [ARGS]...
build-docker
EXPERIMENTAL: Builds a Docker image whose default entrypoint serves the specified MLflow model at port 8080 within the container, using the ‘python_function’ flavor.
For example, the following command builds a docker image named ‘my-image-name’ that serves the model from run ‘some-run-uuid’ at run-relative artifact path ‘my-model’:
mlflow models build-docker -m "runs:/some-run-uuid/my-model" -n "my-image-name"
We can then serve the model, exposing it at port 5001 on the host via:
docker run -p 5001:8080 "my-image-name"
NB: by default, the container will start nginx and gunicorn processes. If you don’t need the nginx process to be started (for instance if you deploy your container to Google Cloud Run), you can disable it via the DISABLE_NGINX environment variable:
docker run -p 5001:8080 -e DISABLE_NGINX=true "my-image-name"
See https://www.mlflow.org/docs/latest/python_api/mlflow.pyfunc.html for more information on the ‘python_function’ flavor.
This command is experimental (may be changed or removed in a future release without warning) and does not guarantee that the arguments nor format of the Docker container will remain the same.
mlflow models build-docker [OPTIONS]
Options
predict
Generate predictions in json format using a saved MLflow model. For information about the input data formats accepted by this function, see the following documentation: https://www.mlflow.org/docs/latest/models.html#built-in-deployment-tools.
mlflow models predict [OPTIONS]
Options
-
-m,--model-uri<model_uri> URI to the model. A local path, a ‘runs:/’ URI, or a remote storage URI (e.g., an ‘s3://’ URI). For more information about supported remote URIs for model artifacts, see https://mlflow.org/docs/latest/tracking.html#artifact-stores [required]
-
-o,--output-path<output_path> File to output results to as json file. If not provided, output to stdout.
-
-j,--json-format<json_format> Only applies if the content type is ‘json’. Specify how the data is encoded. Can be one of {‘split’, ‘records’} mirroring the behavior of Pandas orient attribute. The default is ‘split’ which expects dict like data: {‘index’ -> [index], ‘columns’ -> [columns], ‘data’ -> [values]}, where index is optional. For more information see https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.read_json.html
prepare-env
EXPERIMENTAL: Performs any preparation necessary to predict or serve the model, for example downloading dependencies or initializing a conda environment. After preparation, calling predict or serve should be fast.
This method is experimental and may be removed in a future release without warning.
mlflow models prepare-env [OPTIONS]
Options
-
-m,--model-uri<model_uri> URI to the model. A local path, a ‘runs:/’ URI, or a remote storage URI (e.g., an ‘s3://’ URI). For more information about supported remote URIs for model artifacts, see https://mlflow.org/docs/latest/tracking.html#artifact-stores [required]
serve
Serve a model saved with MLflow by launching a webserver on the specified host and port. For information about the input data formats accepted by the webserver, see the following documentation: https://www.mlflow.org/docs/latest/models.html#built-in-deployment-tools.
You can make requests to POST /invocations in pandas split- or record-oriented formats.
Example:
$ mlflow models serve -m runs:/my-run-id/model-path &
$ curl http://127.0.0.1:5000/invocations -H 'Content-Type: application/json' -d '{
"columns": ["a", "b", "c"],
"data": [[1, 2, 3], [4, 5, 6]]
}'
mlflow models serve [OPTIONS]
Options
-
-m,--model-uri<model_uri> URI to the model. A local path, a ‘runs:/’ URI, or a remote storage URI (e.g., an ‘s3://’ URI). For more information about supported remote URIs for model artifacts, see https://mlflow.org/docs/latest/tracking.html#artifact-stores [required]
-
-h,--host<host> The network address to listen on (default: 127.0.0.1). Use 0.0.0.0 to bind to all addresses if you want to access the tracking server from other machines.
run
Run an MLflow project from the given URI.
For local runs, the run will block until it completes. Otherwise, the project will run asynchronously.
If running locally (the default), the URI can be either a Git repository URI or a local path. If running on Databricks, the URI must be a Git repository.
By default, Git projects run in a new working directory with the given parameters, while local projects run from the project’s root directory.
mlflow run [OPTIONS] URI
Options
-
-e,--entry-point<entry_point> Entry point within project. [default: main]. If the entry point is not found, attempts to run the project file with the specified name as a script, using ‘python’ to run .py files and the default shell (specified by environment variable $SHELL) to run .sh files
-
-P,--param-list<param_list> A parameter for the run, of the form -P name=value. Provided parameters that are not in the list of parameters for an entry point will be passed to the corresponding entry point as command-line arguments in the form –name value
-
-A,--docker-args<docker_args> A docker run flag or argument, of the form -A name=value. Where name will then be propagated as docker run –name value.
-
--experiment-name<experiment_name> Name of the experiment under which to launch the run. If not specified, ‘experiment-id’ option will be used to launch run.
-
-b,--backend<backend> Execution backend to use for run. Supported values: ‘local’, ‘databricks’, kubernetes (experimental). Defaults to ‘local’. If running against Databricks, will run against a Databricks workspace determined as follows: if a Databricks tracking URI of the form ‘databricks://profile’ has been set (e.g. by setting the MLFLOW_TRACKING_URI environment variable), will run against the workspace specified by <profile>. Otherwise, runs against the workspace specified by the default Databricks CLI profile. See https://github.com/databricks/databricks-cli for more info on configuring a Databricks CLI profile.
-
-c,--backend-config<backend_config> Path to JSON file (must end in ‘.json’) or JSON string which will be passed as config to the backend. The exact content which should be provided is different for each execution backend and is documented at https://www.mlflow.org/docs/latest/projects.html.
-
--no-conda If specified, will assume that MLmodel/MLproject is running within a Conda environment with the necessary dependencies for the current project instead of attempting to create a new conda environment.
-
--storage-dir<storage_dir> Only valid when
backendis local.MLflow downloads artifacts from distributed URIs passed to parameters of type ‘path’ to subdirectories of storage_dir.
-
--run-id<run_id> If specified, the given run ID will be used instead of creating a new run. Note: this argument is used internally by the MLflow project APIs and should not be specified.
Arguments
Environment variables
-
MLFLOW_EXPERIMENT_NAME Provide a default for
--experiment-name
-
MLFLOW_EXPERIMENT_ID Provide a default for
--experiment-id
-
MLFLOW_TMP_DIR Provide a default for
--storage-dir
runs
Manage runs. To manage runs of experiments associated with a tracking server, set the MLFLOW_TRACKING_URI environment variable to the URL of the desired server.
mlflow runs [OPTIONS] COMMAND [ARGS]...
delete
Mark a run for deletion. Return an error if the run does not exist or
is already marked. You can restore a marked run with restore_run,
or permanently delete a run in the backend store.
mlflow runs delete [OPTIONS]
Options
describe
All of run details will print to the stdout as JSON format.
mlflow runs describe [OPTIONS]
Options
list
List all runs of the specified experiment in the configured tracking server.
mlflow runs list [OPTIONS]
Options
-
-v,--view<view> Select view type for list experiments. Valid view types are ‘active_only’ (default), ‘deleted_only’, and ‘all’.
Environment variables
-
MLFLOW_EXPERIMENT_ID Provide a default for
--experiment-id
sagemaker
Serve models on SageMaker.
To serve a model associated with a run on a tracking server, set the MLFLOW_TRACKING_URI environment variable to the URL of the desired server.
mlflow sagemaker [OPTIONS] COMMAND [ARGS]...
build-and-push-container
Build new MLflow Sagemaker image, assign it a name, and push to ECR.
This function builds an MLflow Docker image. The image is built locally and it requires Docker to run. The image is pushed to ECR under current active AWS account and to current active AWS region.
mlflow sagemaker build-and-push-container [OPTIONS]
Options
delete
Delete the specified application. Unless --archive is specified, all SageMaker resources
associated with the application are deleted as well.
By default, unless the --async flag is specified, this command will block until
either the deletion process completes (definitively succeeds or fails) or the specified timeout
elapses.
mlflow sagemaker delete [OPTIONS]
Options
-
-ar,--archive If specified, resources associated with the application are preserved. These resources may include unused SageMaker models and endpoint configurations that were previously associated with the application endpoint. Otherwise, if –archive is unspecified, these resources are deleted. –archive must be specified when deleting asynchronously with –async.
-
--async If specified, this command will return immediately after starting the deletion process. It will not wait for the deletion process to complete. The caller is responsible for monitoring the deletion process via native SageMaker APIs or the AWS console.
-
--timeout<timeout> If the command is executed synchronously, the deployment process will return after the specified number of seconds if no definitive result (success or failure) is achieved. Once the function returns, the caller is responsible for monitoring the health and status of the pending deployment via native SageMaker APIs or the AWS console. If the command is executed asynchronously using the –async flag, this value is ignored.
deploy
Deploy model on Sagemaker as a REST API endpoint. Current active AWS account needs to have correct permissions setup.
By default, unless the --async flag is specified, this command will block until
either the deployment process completes (definitively succeeds or fails) or the specified
timeout elapses.
For more information about the input data formats accepted by the deployed REST API endpoint, see the following documentation: https://www.mlflow.org/docs/latest/models.html#sagemaker-deployment.
mlflow sagemaker deploy [OPTIONS]
Options
-
-m,--model-uri<model_uri> URI to the model. A local path, a ‘runs:/’ URI, or a remote storage URI (e.g., an ‘s3://’ URI). For more information about supported remote URIs for model artifacts, see https://mlflow.org/docs/latest/tracking.html#artifact-stores [required]
-
--mode<mode> The mode in which to deploy the application. Must be one of the following: create, add, replace
-
-ar,--archive If specified, any SageMaker resources that become inactive (i.e as the result of an update in replace mode) are preserved. These resources may include unused SageMaker models and endpoint configurations that were associated with a prior version of the application endpoint. Otherwise, if –archive is unspecified, these resources are deleted. –archive must be specified when deploying asynchronously with –async.
-
-t,--instance-type<instance_type> The type of SageMaker ML instance on which to deploy the model. For a list of supported instance types, see https://aws.amazon.com/sagemaker/pricing/instance-types/.
-
-c,--instance-count<instance_count> The number of SageMaker ML instances on which to deploy the model
-
-v,--vpc-config<vpc_config> Path to a file containing a JSON-formatted VPC configuration. This configuration will be used when creating the new SageMaker model associated with this application. For more information, see https://docs.aws.amazon.com/sagemaker/latest/dg/API_VpcConfig.html
-
-f,--flavor<flavor> The name of the flavor to use for deployment. Must be one of the following: [‘python_function’, ‘mleap’]. If unspecified, a flavor will be automatically selected from the model’s available flavors.
-
--async If specified, this command will return immediately after starting the deployment process. It will not wait for the deployment process to complete. The caller is responsible for monitoring the deployment process via native SageMaker APIs or the AWS console.
-
--timeout<timeout> If the command is executed synchronously, the deployment process will return after the specified number of seconds if no definitive result (success or failure) is achieved. Once the function returns, the caller is responsible for monitoring the health and status of the pending deployment via native SageMaker APIs or the AWS console. If the command is executed asynchronously using the –async flag, this value is ignored.
run-local
Serve model locally running in a Sagemaker-compatible Docker container.
mlflow sagemaker run-local [OPTIONS]
Options
server
Run the MLflow tracking server.
The server which listen on http://localhost:5000 by default, and only accept connections
from the local machine. To let the server accept connections from other machines, you will need
to pass --host 0.0.0.0 to listen on all network interfaces
(or a specific interface address).
mlflow server [OPTIONS]
Options
-
--backend-store-uri<backend_store_uri> URI to which to persist experiment and run data. Acceptable URIs are SQLAlchemy-compatible database connection strings (e.g. ‘sqlite:///path/to/file.db’) or local filesystem URIs (e.g. ‘file:///absolute/path/to/directory’). By default, data will be logged to the ./mlruns directory.
-
--default-artifact-root<default_artifact_root> Local or S3 URI to store artifacts, for new experiments. Note that this flag does not impact already-created experiments. Default: Within file store, if a file:/ URI is provided. If a sql backend is used, then this option is required.
ui
Launch the MLflow tracking UI for local viewing of run results. To launch a production server, use the “mlflow server” command instead.
The UI will be visible at http://localhost:5000 by default, and only accept connections
from the local machine. To let the UI server accept connections from other machines, you will
need to pass --host 0.0.0.0 to listen on all network interfaces (or a specific interface
address).
mlflow ui [OPTIONS]
Options
-
--backend-store-uri<backend_store_uri> URI to which to persist experiment and run data. Acceptable URIs are SQLAlchemy-compatible database connection strings (e.g. ‘sqlite:///path/to/file.db’) or local filesystem URIs (e.g. ‘file:///absolute/path/to/directory’). By default, data will be logged to the ./mlruns directory.