Deploy Lab — Container to Cloud URL
- Deploy the containerized capstone to one real, publicly reachable URL
- Configure environment variables and secrets safely on the host, never in the image
- Put the service behind TLS with a domain or platform-provided HTTPS endpoint
- Run smoke tests against the live URL and tear down cleanly with cost hygiene
| Spaced-rep warm-up: Docker/Compose/cloud cards (D148–150) | 10 min |
| Read the deployment path + TLS/smoke-test/teardown plan | 15 min |
| Guided: ship to a live HTTPS URL | 30 min |
| Guided: smoke-test the live service, then tear down | 25 min |
| Practice: secrets-and-teardown checklist | 15 min |
| Finalize RUNBOOK.md + quiz + flashcards | 15 min |
Builds on: Day 148 — Docker fundamentals · Day 149 — Compose, registries & image hygiene · Day 150 — Cloud fundamentals
You've built the restaurant, packed it into a shippable kitchen, and picked which building to rent. Today you unlock the front door and let the public in. That means a real address someone can type, a lock on the door so conversations aren't overheard (TLS/HTTPS), the keys to the pantry handled carefully (secrets given to the running kitchen, never printed on the menu), and a walk-through before opening to check the lights turn on and the food actually comes out (smoke tests). And because you're renting by the minute, you learn to lock up and stop the meter when the night's over (teardown), so a practice run doesn't cost you a month's rent.
This is a project day: less new theory, more shipping. By the end, a colleague on another network can open a link and ask your docs-QA service a real question, over HTTPS, with your API keys safely on the server and nowhere in the image or the repo. Then you tear it down and confirm the meter stopped.
A capstone that only runs on localhost is a demo, not a product — and "can a stranger reach it over HTTPS?" is the line between the two. This is the FDE's core deliverable made concrete: software running in a real environment a customer can touch (Day 170 does it inside their VPC). The disciplines you practice today — secrets on the host not in the image, TLS by default, smoke tests before you trust it, teardown so the bill stays sane — are exactly what a production cutover (Day 161) and a customer security review (Day 159) demand. Interviewers and hiring managers weight "have you actually deployed something?" heavily; a live URL you can show, then explain the cost and teardown of, is a strong portfolio signal.
Guided practice
Ship it to a live HTTPS URL
25 min- Pick your Day-150 target. Fastest path: a PaaS container platform with a free tier that gives an HTTPS URL and secret storage.
- Push your tagged slim image (Day 149) to a registry the platform can read, or connect the repo so the platform builds it.
- Set secrets as platform environment variables:
ANTHROPIC_API_KEY, the vector-store URL/key,APP_ENV=prod. Confirm none of these are in the image or git (grep the repo to be sure). - Configure persistent state: attach a managed vector store or a disk/volume so the index survives restarts. Ingest a small corpus if the index starts empty.
- Deploy. Capture the public URL. terminal (from your laptop):
curl https://YOUR_URL/health— expect{"ok":true}over HTTPS. - If on a raw VM instead: run the Compose stack, add the Caddyfile above, point DNS at the VM, and confirm
https://works with a valid certificate.
Smoke-test the live service, then tear down
20 min- Write
deploy/smoke_test.py(or a shell script) that targets the live URL and asserts:/healthok; one real docs-QA query returns an answer containing a citation; an out-of-scope question is refused; the response includes anX-Trace-IDheader. - Run it from your laptop against the public URL. terminal:
python deploy/smoke_test.py https://YOUR_URL. All assertions must pass — fix any that don't (a common one: secrets not actually set, so generation errors). - Record the results and the live URL in
deploy/RUNBOOK.md(started today, expanded on Day 161). - Write the exact teardown commands for your platform into the runbook.
- Tear down: stop/delete the compute and any idle volumes/load balancers, then open the billing page and confirm nothing is still accruing. Keep the registry image.
- Note the deploy's rough hourly/daily cost while it was up — feeds Day 173's ROI one-pager.
On your own
The secrets-and-teardown checklist
15 minWrite two short checklists into deploy/RUNBOOK.md and then actually run them against your deployment. (1) Secrets audit: list every secret the service needs, where each is set (platform env / secret store), and prove none is in the image (docker history shows no ENV secret) or in git (git grep for a key prefix returns nothing). (2) Teardown checklist: every billable resource you created, the exact command/console step to remove it, and the verification that it's gone from the billing page. Run the secrets audit now; run the teardown at the end of the lab and tick each box.
Hints: the two most common leaks are a real key committed in a .env that wasn't in .gitignore, and a key passed via ENV in the Dockerfile. The two most common cost leaks are an orphaned volume and a load balancer left running after the container is gone.
Capstone live at a public HTTPS URL
Deploy your containerized docs-QA service to one real, publicly reachable HTTPS URL and prove it works from outside your network, then tear it down cleanly. Deliver in deploy/RUNBOOK.md: the live URL (while up), the platform and region chosen, the exact deploy steps, the secrets audit (nothing in image or git), the passing smoke-test output run from your laptop, and the teardown steps with billing-cleared confirmation. The live service must answer a real docs-QA query end to end (retrieval + grounded answer + citation), refuse an out-of-scope question, serve over valid TLS, and return the X-Trace-ID header. Record the rough running cost. Keep the tagged image in the registry so Day 154's pipeline can redeploy it automatically.
Common mistakes & misconceptions
- Putting secrets in the image or repo to "just get it working." A key in a layer or a committed .env is a leak that outlives the deploy — set secrets on the platform, always.
- Testing only from the server or localhost. Smoke-test from your laptop over the public URL, or you never actually verify the path real users take.
- Storing the vector index on the container filesystem. It vanishes on restart/redeploy; state needs a managed store or an attached volume.
- Shipping over plain HTTP. Customers and browsers reject it; use a managed HTTPS endpoint or a two-line Caddyfile for automatic Let's Encrypt certs.
- Leaving the deployment running after the lab. The meter doesn't care that you're done; tear down compute and idle volumes/load balancers and confirm the bill is clear.
- No runbook. If the deploy steps live only in your shell history, you can't reproduce or hand off the deployment — write them down as you go.
Q1. Why run the smoke test from your laptop against the public URL rather than from the server?
Q2. Where do the ANTHROPIC_API_KEY and vector-store credentials belong in a cloud deployment?
Q3. You finish the deploy lab. What is the cost-hygiene step most teams forget?
Go deeper — curated resources
- Persistent vector store options in the cloud ↗ — Compare running Qdrant on a disk-backed container vs a managed vector service vs pgvector on a managed Postgres — statefulness is what makes cloud deployment of a RAG app non-trivial.
- Capstone reachable at a public HTTPS URL and answering a real query from outside your network
- Secrets audit passes: none in image or git; TLS valid; X-Trace-ID returned
- Smoke test green from the laptop against the live URL
- Clean teardown with billing confirmed clear; running cost recorded; image kept
- RUNBOOK.md started with deploy + teardown steps; quiz ≥ 2/3
← Back: This runs the Day-148 image and Day-149 Compose stack on the Day-150 tier you chose, and finally exposes the capstone you've grown since Day 119 to the public internet over TLS.
Forward →: Day 152 automates this exact build-push-deploy in GitHub Actions; Day 153 expresses the provisioned resources as code; Day 154 makes push-to-main deploy to a staging URL, and Day 161 turns today's runbook into the full production cutover.
Unlocks: D152 CI/CD with GitHub Actions · D153 Infrastructure as Code & Environments · D154 Week 22 Checkpoint: Staging Pipeline · D155 Serving & Inference Optimization