Docker runtime and config

To serve a model reliably you have to answer "will it run the same on my laptop, in CI, and in production?" The answer is packaging the runtime and separating config from code.

Reproducible packaging (Docker)

A Docker image bundles your code with a pinned runtime — exact Python version, exact dependency versions, the model file. Anyone who runs the image gets the same environment, so "works on my machine" becomes "works everywhere." The key word is pinned: numpy==1.26.4, not numpy (which floats and breaks reproducibility). In prose that's a Dockerfile; the idea is "one artifact, same behavior."

Config and secrets via environment, not the image

What changes per deployment — worker count, timeouts, the model version, API keys — must come from the environment, not be hard-coded into the image:

• Bake config in and you need a new image for every tweak, and you can't vary staging vs prod from one artifact.
• Bake secrets in and they leak with the image.

The pattern: declare defaults in code, let the environment override them. Run the editor — same defaults, env supplies workers=4 and model=v3, and env wins.

Why a builder cares

Two classic outages: "it ran in staging but the prod container has a different numpy" (unpinned deps) and "we shipped a new image just to bump a timeout" (config baked in). Pin the runtime, read config from env. You'll write the defaults-plus-env merge next.