What This Module Covers

“Works on my machine” is not a joke, it is a category of outage — the model trains, the metric holds, the artifact reloads, and none of it survives contact with a machine that has never seen your code. The serialized model you trust is the thing you hand off, and handing it off is almost the easy part. The hard part is everything around it: whether the same dependencies install, whether a teammate’s build matches yours, whether a secret rode along in the package, and whether the thing runs identically somewhere that is not your laptop. This module closes that gap with a container — the whole environment frozen into one shippable image.

What this module is

By now you have a model that trains, a metric you trust, and a serialized artifact that reloads and predicts the same as the model that produced it. An artifact is the thing you hand off. Handing it off is almost the easy part. The hard part is everything around it: whether the same dependencies install, whether a teammate’s build matches yours, whether a secret rode along in the package, and whether the thing survives the trip from your machine to production unchanged.

Packaging here means Docker — a container image, the whole environment frozen into one shippable artifact built in ordered layers. This is the container layer of reproducibility, not the virtual-environment layer the Python module already covered. The lock file from that module becomes load-bearing inside the image, and the judgment this module teaches is about shipping a working image well: one that builds the same twice, carries no credential, and weighs what it needs to weigh and no more.

What you will learn

The module moves through six lessons, following the order the work actually happens in — get it working, make it right, then make it run. Lesson 1 builds an image that runs; the next three are the hardening pass, each going back to the working image and fixing a real problem; the last two are the run pass, turning the hardened image into a long-lived service and then composing it with another service into a one-command app.

• Get a working image that runs the model. Write a Dockerfile, build it, run it, and score a record end to end on the happy path. You will learn what an image, a layer, and a container are, why docker build and docker run happen at different times, and how ENTRYPOINT makes scoring a record a single command. The image runs; the rest of the module hardens it.
• Make the build reproducible. The image runs, but an unpinned install resolves to whatever is newest at build time, so the same Dockerfile built a week apart produces two different environments — and two different models. You will install from the locked dependency graph and order the layers so the dependency install caches across code edits instead of re-running on every change.
• Make it safe to run anywhere. A reproducible image that ships its secrets is reproducibly insecure. You will read configuration from the environment at run time instead of baking it in, learn why a secret deleted in a later layer is still recoverable from the earlier one (so a leaked credential must be rotated, not removed), and use a .dockerignore to control what even enters the build context.
• Make it slim. The full numeric stack can push an image to several gigabytes that nobody can push or pull fast enough. You will name “works on my machine” as a specific class of missing-environment failure, choose a base image deliberately rather than by default, and use a multi-stage build to compile in a fat builder stage and ship only the finished artifacts in a thin runtime stage — same model, a fraction of the size.
• Run it as a service, not a script. A score-and-exit container completes and disappears, so nothing is left for a later request to reach. You will run a blocking server as the container’s main process so it stays up, publish its port and bind 0.0.0.0 so something off the container can reach it, and mount state on a volume so it survives the container being removed.
• Compose the stack. A real app is more than one service, and wiring two containers with a page of remembered docker run flags is reproducible by no one. You will replace those flags with one declarative compose.yaml that comes up on a single command, has services find each other by service name instead of localhost, and gates the frontend on the backend being ready (the model loaded), not merely started.

The module ends with a project you run on your own machine, starting from the Phase 2 starter: a reproducible, slim Docker image of the Adult / Census Income model — locked dependencies and a pinned base, configuration through one typed settings object with a fail-fast on missing values, no secret in any layer, a long-lived service reachable on a published port, and a compose.yaml that brings the scorer up beside a Postgres dependency it waits on for readiness. The lessons work the techniques on the Lending Club scorer; the project is where you prove them yourself, against a rubric that maps line by line to these lessons.

How it builds on what came before

Every lesson here stands on the earlier modules. The serialized model artifact you trust is the thing this module packages — the whole point is to make it run somewhere other than the box that produced it. The dependency lock file from the Python module becomes load-bearing inside the image: it is what turns “it builds” into “it builds the same.” The judgment about what belongs in version control returns one boundary over, as the judgment about what belongs in the build context — source in, regenerable and large and secret out. Nothing here asks you to abandon what you built; it extends it across the gap between machines.

What you will be able to do

By the end you will write a Dockerfile, build an image that runs the model and scores a record with one command, make that build reproducible from a clean machine, keep configuration and secrets out of the layers, ship a slim image that does the same job at a fraction of the size, run that image as a long-lived service reachable on a published port, and compose it with a second service into an app that comes up on one command. The thread through all six lessons is the same: the model is the easy part, and making it run identically anywhere is the job.