The packaging problem
A model file alone cannot serve predictions. It needs the same library versions, preprocessing code, and runtime it was built with. A container bundles all of this into one portable image.
What goes in the image
- The model artifact loaded at startup.
- The inference code that preprocesses inputs and runs the model.
- The dependencies pinned to exact versions in the build.
- A defined entrypoint that starts the serving process.
Why containers fit
A container image is immutable and self contained, so it runs identically on a laptop, a CI runner, and production. The same image you tested is the one you ship, which removes the it works on my machine class of failures.
Tagging and promotion
Images are tagged by version and stored in an image registry. Deployment pulls a specific tag, so rollback is just deploying a previous tag.
Key idea
Containerizing packages the model, inference code, and pinned dependencies into one immutable image that runs identically everywhere, ending environment drift.