What is configuration as code for an ML application?

Configuration as code means storing an ML application's adjustable settings in structured, reviewable configuration rather than scattering fixed values throughout Python scripts or notebooks.

For example, the model's learning rate, input dataset reference, feature choices, evaluation threshold, and prediction timeout can be settings. The code explains how the application works; configuration chooses how it should run for a particular job or environment.

A beginner-friendly example

Imagine a food-delivery company training a model to predict delivery times.

Initially, its training script contains fixed values such as learning_rate = 0.01 and batch_size = 64. To try different settings, an engineer must edit the script each time. That makes reviews noisy and complicates comparisons between experiments.

Instead, the team creates a small, non-secret YAML configuration file:

YAML
# configs/train.yaml
model:
  learning_rate: 0.01
  batch_size: 64

data:
  dataset_version: "orders-2026-10"
  target_column: "delivery_minutes"

evaluation:
  max_mae_minutes: 8.0

The training code reads this file and uses the selected settings. To try a batch size of 128, the team changes the configuration or supplies a supported command-line override—without rewriting the training algorithm.

Here, MAE (mean absolute error) is the average absolute difference between predicted and actual delivery times. The max_mae_minutes setting is an example of a target the team checks before considering a model for release; it is not a universally correct threshold.

How should a team manage configurations?

1. Separate code from choices. Keep reusable logic in code and adjustable values in clearly named configuration files, such as configs/train.yaml.
2. Version non-secret configuration in Git. Review setting changes in pull requests alongside relevant code changes.
3. Validate values before running. Check required fields, expected data types, and sensible ranges. For example, a batch size should be a positive integer.
4. Track the actual values used. Save the *resolved* configuration with the training-run record, along with its Git commit and dataset version. This matters if defaults or command-line overrides changed the effective settings.
5. Allow safe overrides. Tools such as Hydra can compose configuration files and override parameters from the command line, which helps experiments stay organized.
6. Keep secrets separate. Store passwords, tokens, and service credentials in an appropriate secrets manager or securely injected environment variables—not in Git-tracked YAML files or experiment logs.

For instance, an experiment tracker such as MLflow can record the parameters used in each training run, allowing the team to compare results later.

How is this different from Infrastructure as Code (IaC)?

IaC defines resources the application runs on, such as cloud storage, network settings, and training compute.

Configuration as code defines the application's behavior, such as which dataset version to read, which features to use, or what prediction timeout to enforce.

They complement each other: IaC can provision a training service, while application configuration controls an individual training run.

What about development, staging, and production?

Some settings should differ between environments, such as endpoints and resource references. But avoid copying entire files unnecessarily; share common defaults and override only what truly differs. The next concept explores how to manage those differences safely.

In short: Configuration as code makes ML settings visible, testable, versionable, and reproducible, while allowing one codebase to support many controlled experiments and deployments.