How do you make an ML application twelve-factor friendly?

A twelve-factor application follows a set of practices for making software easier to deploy, operate, and scale. The original Twelve-Factor App methodology was written for services, but many of its principles also help production ML systems.

In MLOps, the aim is not to force all model training into a web-service design. Instead, apply these principles especially to model-serving APIs, background workers, and the processes that deploy them.

A practical example

A food-delivery company has trained a model that predicts delivery time. It wants to run a reliable prediction API.

The first version works only on an engineer's laptop: it loads a model from a personal folder, writes predictions to a local CSV file, and needs someone to restart it manually. If a second server starts, it cannot find the same model or prediction history.

A twelve-factor-friendly design makes each API instance replaceable: the model is fetched by a specific approved version, durable results go to a database, runtime settings come from the deployment environment, and the platform handles logs and restarts.

Applying the twelve factors to the ML service

1. Codebase — One version-controlled codebase, many deployments. Keep the prediction service in Git. Development, staging, and production deploy reviewed revisions of that codebase. Related training services may have their own codebases.

2. Dependencies — Declare and isolate what the service needs. Record Python libraries and required runtimes. Build the service with its tested dependencies rather than relying on whatever happens to be installed on a particular server.

3. Config — Keep deployment settings outside the code. Set values such as the approved model version, artifact location, and request timeout through the deployment's configuration mechanism. Supply sensitive credentials using an approved secret or workload-identity system.

For instance, the application can read non-secret settings at startup:

PYTHON
import os

MODEL_VERSION = os.environ["MODEL_VERSION"]
MODEL_STORE_URI = os.environ["MODEL_STORE_URI"]

The serving code can then use these values to retrieve the approved, fixed model artifact. Neither the model file nor credentials need to be hard-coded into the source.

4. Backing services — Treat storage and databases as attached resources. A model registry, object store, database, and message queue are external services reached through configured endpoints. Replacing a test store with an approved production store should not require editing the prediction algorithm.

5. Build, release, run — Keep these stages separate. Build a tested container or application artifact, combine it with environment-specific configuration to form a release, and then run it. Do not silently install new packages or train a new model every time the prediction server starts.

6. Processes — Keep the serving process stateless. An API instance may cache the loaded model in memory for speed, but it must not depend on local disk or process memory for *durable* predictions, user sessions, or other shared business state. Store those externally.

7. Port binding — Expose the prediction API through a service port. A Python API could listen on a configured port while the deployment platform routes requests to it.

8. Concurrency — Scale using replaceable processes. If traffic grows, run additional prediction-service replicas behind a load balancer. For expensive GPU models, measure memory use, batching, and throughput: blindly adding processes may exhaust accelerator memory.

9. Disposability — Start and stop safely. Make startup and health checks explicit. On shutdown, stop accepting new work, allow in-flight requests to finish within a deadline, and let queue workers safely requeue or checkpoint unfinished work. Very large models can take time to load, so realistic readiness checks matter more than promising instantaneous startup.

10. Dev/prod parity — Test production-like behavior. Verify the candidate image, model version, input schema, and critical service integrations before release; use isolated non-production data and credentials.

11. Logs — Emit event streams. Write structured, privacy-safe request and error logs to standard output/error and let the runtime platform collect them. Avoid storing the only copy of logs on a container's local filesystem.

12. Admin processes — Run maintenance as separate tasks. Database migrations, backfills, and one-time model-index updates should be controlled jobs using the appropriate application release, not ad-hoc changes inside a running prediction API.

What about long-running ML training?

Training is often *intentionally stateful while it runs*. It holds model weights and optimizer state in memory, perhaps for hours. Twelve-factor thinking is still useful: place durable checkpoints, datasets, and final models in external versioned storage so a worker can be restarted or replaced safely.

The earlier lessons on configuration, environment parity, immutable artifacts, and idempotent retries explain those individual controls. Twelve-factor design brings them together into an operating model for a deployable ML service.

In short: Make your serving code versioned, its dependencies explicit, its runtime configurable, its durable state external, and its processes replaceable. That turns a laptop-only prediction script into a service that is easier to test, scale, and recover.