What This Module Covers

Everything you have built so far is reachable by exactly one person: you. The model, the slim reproducible image, the serving endpoint, the dashboard in front of it — all of it runs on a single computer that no stranger can reach, and a model nobody outside your laptop can call is not yet a product. The distance between “it works” and “it works for someone else” is the entire subject of this module. It puts the dockerized service at a real public URL, on a real domain, over TLS, with a deploy you can undo and a bill you have bounded in advance.

What this module is

Deployment is the act of taking the image the packaging module built and running it on a computer that is not yours, then making the rest of the internet able to reach it safely and affordably. Getting a 200 OK back from a public URL is almost the easy part. The hard part is everything around it: the deploy that reports success while the service is unreachable, the rebuild that ships a different artifact than the one you tested, the first production URL that fails for an hour for reasons that are completely normal, the bad version that needs to come back out under live traffic, and the idle service that quietly bills you for weeks.

This module is deliberately platform-shaped, not platform-specific. It uses a scale-to-zero container host as the concrete example, but the judgment it teaches — promote the tested artifact, treat readiness as separate from liveness, expect DNS and certificates to lag, keep rollback one step away, state the worst-case cost out loud — transfers to any host you deploy to.

What you will learn

The module moves through five lessons, in the order the work happens: get it live, then make every property you would be paged about hold.

• Get the service live on the internet. Push the dockerized /predict image to a container host and score a Lending Club record at a public URL, end to end. You will learn why a deploy can go green while the service is unreachable — a server bound to 127.0.0.1 answers only itself — and why the host injects the port it expects you to bind.
• Promote, do not just push. A second docker build is not the artifact you tested; it is a new one that happens to share a Dockerfile. You will promote the exact image you verified by its content digest, keep configuration in the environment so one artifact runs in every stage, and see why a baked secret survives in a layer even after a later layer deletes it.
• DNS and TLS: why your first prod URL fails. Putting the service on a real domain over https:// fails for about an hour, and that hour is normal. You will learn DNS resolution and certificate provisioning as two clocks chained in series — propagation governed by TTL, the certificate by an ACME challenge — so the outage reads as expected rather than broken.
• Make failure cheap. A deploy you cannot undo is a deploy you are afraid to do. You will choose how new versions roll out, gate the cutover on a readiness probe that actually means can-serve rather than is-alive, and guarantee a one-step rollback to the last good version while real traffic is flowing.
• Bound the cost before it bounds you. A scale-to-zero service can idle near free or bill you for weeks unnoticed. You will pick the billing model from where the service sits on the traffic curve and convert the worst-case monthly figure from an unknown into a number you have said out loud.

The module ends with a project on your own cloud account: the Adult / Census Income scorer deployed publicly — a stranger’s curl scoring a record over https:// on a domain you control, one image digest promoted from dev to prod, a rollback you can demonstrate in one command, and a cost ceiling whose monthly number you can state. The lessons harden the Lending Club deploy; the project is where you ship yours, against a rubric that maps line by line to these lessons — and the proof is a live URL, not a screenshot.

How it builds on what came before

This module is where everything upstream finally leaves your machine. The slim, reproducible image from the packaging module is the unit that gets deployed — its content digest is what you promote, so the build-once-deploy-many discipline that started inside the image now spans environments. The readiness-versus-liveness distinction is the serving module’s health check grown into a release gate. The honesty thread continues too: the serving endpoint refused bad input, the dashboard refused to show a number it could not stand behind, and this module refuses to call a deploy successful until a real request to /predict returns from a public URL. Nothing here is new infrastructure for its own sake; it carries the artifact you already trust across the gap to a machine the world can reach.

What you will be able to do

By the end you will deploy the dockerized model to a container host and score a record at a public URL, promote the tested artifact by digest instead of rebuilding it, put the service on a domain over TLS and recognize the normal first-hour failure for what it is, roll a bad version back in one step under live traffic, and state the expected and worst-case monthly cost before you ship. The thread through all five lessons is the same: making the service answer once is the demo, and making it answer safely, durably, and affordably to anyone is the job.