Objective
Finalize docker-compose.yml, write a setup.sh that rebuilds the whole stack, and prove docker compose down && docker compose up restores everything correctly.
Build
The capstone project
Everything works, right now, on this machine, because you built it step by step and remember every decision. Today's job: prove it survives you forgetting all of that — a real test of whether this is a system or just a memory.
The real test: tear it down and bring it back
docker compose down
docker compose up -d
docker compose ps
If either service comes back missing your chat history, your uploaded documents, or your Qdrant embeddings, something isn't using a named volume correctly -- go back and check every service's volumes: entry against Lesson 3 and Lesson 4's compose additions.
This is the actual test, not "it ran once"
"It worked when I first set it up" and "it survives being torn down and rebuilt" are different claims. Docker volumes persist data across down/up cycles specifically because you named them (open-webui-data, qdrant-data) rather than using anonymous or bind-mount-to-a-temp-path patterns. Running this teardown/rebuild test yourself, right now, is cheaper than discovering a gap the day your actual machine needs a reinstall.
One script, not a remembered sequence of commands
#!/usr/bin/env bash
set -e
echo "Checking Ollama is running..."
if ! curl -s http://localhost:11434 > /dev/null; then
echo "Ollama not running -- start it first (ollama serve or the Ollama app)"
exit 1
fi
echo "Pulling required models..."
ollama pull qwen3:8b
ollama pull qwen3-coder:7b
ollama pull nomic-embed-text
echo "Starting Docker Compose stack..."
docker compose up -d
echo "Waiting for services to become healthy..."
sleep 5
docker compose ps
setup.sh is the file that makes the difference between "I have a local AI stack" (true only on this specific machine, only because you remember the steps) and "I have a reproducible local AI stack" (true on any machine, because the steps are written down and executable). This is the exact same "the real test is a directory that doesn't already work" principle from Course 02's packaging lesson, applied to infrastructure instead of a Python package.
Your setup.sh works perfectly on your current machine. You're about to consider this "done" for the course. What's the one thing worth verifying before you do?
"Works on the machine I wrote it on" is the weakest possible test of reproducibility -- exactly the gap this lesson's opening framed. If you have access to another machine (even a VM or a friend's laptop), running setup.sh there is the real test; if not, a careful read-through for anything hardcoded to your specific environment (an absolute path, an assumption about installed tools) is the next best check.
Ship it
Push docker-compose.yml, setup.sh, and a .env.example to a private GitHub repo. Record a screen capture: Open WebUI open, a question about your own documents answered with a citation, and your system monitor visible showing real local CPU/RAM usage — proof that nothing left your machine.
Ship Prompt: What models are you running? What's your hardware? Share a screenshot of Open WebUI chatting with your own documents. What's the coolest thing you've asked it?