llowing format:

enable_<STACK_COMPONENT>_<FLAVOR>This variable is then passed as input to the underlying modular recipe. If you check the variables.tf file for a given recipe, you can find all the supported flavor-stack component combinations there.

Component Type Flavor(s) Artifact Store s3, gcp, minio Container Registry aws, gcp Experiment Tracker mlflow Orchestrator kubernetes, kubeflow, tekton, vertex MLOps Platform zenml Model Deployer seldon Step Operator sagemaker, vertex

✨ Customizing your stack components

With simplicity, we didn't want to compromise on the flexibility that this deployment method allows. As such, we have added the option to pass configuration specific to the stack components as key-value arguments to the deploy CLI. Here is an assortment of all possible configurations that can be set.

The flags that you pass to the deploy CLI are passed on as-is to the backing modular recipes as input variables. This means that all the flags need to be defined as variables in the respective recipe.

For example, if you take a look at the variables.tf file for a modular recipe, like the gcp-modular recipe, you can find variables like mlflow_bucket that you could potentially pass in.

Validation for these flags does not exist yet at the CLI level, so you must be careful in naming them while calling deploy.

All these extra configuration options are passed in with the -x option. For example, we already saw this in action above when we passed in the GCP project ID to the artifact store deploy command.

zenml artifact-store deploy -f gcp -p gcp -r us-east1 -x project_id=zenml my_store

Simply pass in as many -x flags as you want to customize your stack component.

Experiment Trackers

You can assign an existing bucket to the MLflow experiment tracker by passing the -x mlflow_bucket=... configuration:

zenml experiment-tracker deploy mlflow_tracker --flavor=mlflow -p YOUR_DESIRED_PROVIDER -r YOUR_REGION -x mlflow_bucket=gs://my_bucket

Artifact Stores