Connect Backblaze B2 to MLflow

MLflow stores two kinds of data for each run: metadata (parameters, metrics, and tags) in a backend store, and larger files (model weights, images, and datasets) in an artifact store. By default, the artifact store is a local folder. For a team environment, or for artifacts too large to keep on one machine, MLflow supports several remote storage backends, including Backblaze B2 Cloud Storage.

MLflow includes native support for Backblaze B2 through a b2:// URI scheme. You do not need to configure a generic S3-compatible endpoint manually, unlike some other MLflow-compatible tools.

Connecting Backblaze B2 to MLflow lets you:

• Store model artifacts and experiment outputs outside the tracking server's local disk.

• Share a single artifact location across every machine on your team.

• Keep artifact costs low, since Backblaze B2 is priced for large-scale object storage.

Prerequisites

Make sure the following prerequisites are in place before you begin.

• Backblaze B2 enabled on your account.

• A Backblaze B2 bucket, noting the endpoint host and region.

• A Backblaze B2 application key generated specifically for S3-compatible access. Your account's master application key does not work with the S3-compatible API, so you must generate a new one.

• MLflow and boto3 installed on the machine running the tracking server. If you use direct artifact access, install them on each client machine as well. Run python -m pip install mlflow boto3 if they are not already installed.

Set the Application Key Environment Variables

MLflow authenticates to Backblaze B2 using the same environment variables it uses for Amazon S3.

Set these three environment variables on the machine running the MLflow tracking server, before you start the server:

export AWS_ACCESS_KEY_ID="your_b2_application_key_id"
export AWS_SECRET_ACCESS_KEY="your_b2_application_key"
export AWS_DEFAULT_REGION="your_bucket_region"

Where you set them depends on how you run the server:

• Terminal session: Run the export commands in the same shell you use to start mlflow server. These variables only last for that session, so you need to set them again if you close the terminal or restart the machine.

• Startup script or shell profile: Add the export lines to a startup script, or to a shell profile such as ~/.bashrc or ~/.profile, so the variables persist across reboots.

• systemd service: Add an Environment= line for each variable in the service unit file, for example Environment=AWS_ACCESS_KEY_ID=your_b2_application_key_id.

• Docker or Docker Compose: Pass each variable with -e on the docker run command line, or list them under environment: in your Compose file.

The application key ID and application key come from the key you generated in Prerequisites. The region matches the region shown in your bucket's endpoint host, for example us-west-004 or us-east-005.

If clients log runs to the tracking server directly, rather than through the server's proxy, set these same three variables on each client machine as well.

Configure the Artifact Store

Backblaze B2 artifact locations use the following URI format:

b2://<bucket>@<endpoint-host>/<path>

The endpoint host is usually s3.<region>.backblazeb2.com. You can find the exact value on the Buckets page of the Backblaze web console, listed alongside the bucket you created in Prerequisites. Do not include https:// in the b2:// URI.

For example, a bucket named mlflow-artifacts in the us-west-004 region would use:

b2://mlflow-artifacts@s3.us-west-004.backblazeb2.com/

Start the Tracking Server

Start the MLflow tracking server with the --artifacts-destination flag set to your Backblaze B2 URI. This configuration has the tracking server proxy all artifact uploads and downloads, so client machines do not need direct access to Backblaze B2 or the application key.

mlflow server \
    --host 0.0.0.0 \
    --backend-store-uri sqlite:///mlflow.db \
    --artifacts-destination b2://mlflow-artifacts@s3.us-west-004.backblazeb2.com/

Replace the backend store URI with your production backend (for example, PostgreSQL or MySQL) if you are not using the default SQLite database.

If you would rather have clients write directly to Backblaze B2 without proxying through the server, use --default-artifact-root together with --no-serve-artifacts instead of --artifacts-destination. With that configuration, every client machine needs its own copy of the application key environment variables from the previous section.

mlflow server \
    --host 0.0.0.0 \
    --backend-store-uri sqlite:///mlflow.db \
    --no-serve-artifacts \
    --default-artifact-root b2://mlflow-artifacts@s3.us-west-004.backblazeb2.com/

Confirm the Connection

Log a run from a client with the tracking URI pointed at your server, then check that the artifact lands in the bucket.

from pathlib import Path


import mlflow


mlflow.set_tracking_uri("http://<tracking-server-host>:5000")


Path("some_file.txt").write_text("hello from MLflow and Backblaze B2\n", encoding="utf-8")


with mlflow.start_run():
    mlflow.log_param("test_param", 1)
    mlflow.log_artifact("some_file.txt")

Open the run in the MLflow UI and select the Artifacts tab. If some_file.txt appears there, and the file is visible in your Backblaze B2 bucket through the Backblaze web console, the connection is working. In the bucket, MLflow stores artifacts under experiment and run paths. For the default experiment, the object path begins with 0/<run-id>/artifacts/.

Notes

• The master application key does not work here. Backblaze's S3-compatible API requires a key generated specifically for that purpose. If authentication fails immediately after setup, this is the first thing to check.

• The region must match the bucket, not a default. AWS_DEFAULT_REGION is read by the underlying S3 client library that MLflow uses internally. An incorrect region produces an authentication error that looks unrelated to region settings.

• Proxied access centralizes credentials. With --artifacts-destination, only the tracking server needs the application key. Every user with access to the tracking server can read and write artifacts through it, so treat access to the server itself as equivalent to access to the bucket.

• Existing experiments keep their original artifact location. MLflow records an experiment's artifact location when the experiment is created. If you change the tracking server's artifact configuration, create a new experiment to use the new Backblaze B2 location.

• Backblaze B2 uploads require boto3. MLflow's Backblaze B2 artifact repository uses the S3-compatible client libraries internally. If the server logs show ModuleNotFoundError: No module named 'boto3', install boto3 in the MLflow environment. For direct artifact access, install boto3 on each client machine too.

Next Steps

• Move off SQLite for production. The examples in this guide use a local SQLite database for the backend store. For a team environment, configure --backend-store-uri to point at PostgreSQL or MySQL instead. See the MLflow Backend Store documentation.

• Secure the tracking server. If you set --host 0.0.0.0 to accept connections from other machines, configure --allowed-hosts and consider adding authentication through a reverse proxy. See Secure Tracking Server in the MLflow Tracking Server documentation.

• Tune upload behavior for large artifacts. If your team logs large models or datasets, review MLFLOW_ARTIFACT_UPLOAD_DOWNLOAD_TIMEOUT and the multipart upload settings described in the Artifact Stores documentation.

• Explore more integrations. To learn more about other Backblaze integrations and developer examples, visit Backblaze Labs.

Resources

• MLflow Artifact Stores documentation

• MLflow Tracking Server documentation

• MLflow GitHub repository

• Backblaze B2 S3-Compatible API

• Backblaze Labs