Lesson 8 · This repo's local dev

The local dev loop

The inner loop you live in — from a code edit to a restarted service in seconds, without rebuilding an image.

Your win: trace exactly what ./local/run.bash start -s <svc> does, explain why it's fast (hot-swap, not rebuild), and name the debug and migration modes.

The fast path: hot-swap, not rebuild

Rebuilding the Docker image on every code change would be painfully slow (Lesson 2's layer cascade). The repo avoids it entirely. When you run the normal start for one service, it compiles the Go binary on the host and copies it into the already-running container, which restarts the process in place.

Anchor — local/run.bash:155-163 In "normal mode" the script runs ./local/build-code-golang.bash (compile build/server), then:
docker cp ../build/server local-$service-1:/server (line 161)
That's it — no docker build, no image push, no compose up. The new binary lands on top of the old one and modd (the live-reload entrypoint baked into the image in Lesson 2) notices and restarts /server. Seconds, not minutes.
edit .go ──► run.bash start -s bob │ ├─ build-code-golang.bash → build/server (host compile, cross to linux/amd64) │ └─ docker cp build/server → local-bob-1:/server │ modd sees the change → restarts /server ✓ live

The flags that shape the loop

CommandWhat it does
run.bash (no args)full bring-up: build image, render configs, up the whole stack
start -s bobcompile + hot-swap the binary into local-bob-1
start -b false -s bobsame, but skip the Docker image rebuild step (copy only)
start -m migration -s bobrun the migration container first, then start the service
start -m debug -s bobrun under the Delve debugger on port 40000
stop / stop -s bobtear down all (drops kafka + postgres volumes) / one service
bdd -s bobrun BDD tests inside local-gandalf-1
Anchor — the other modes Debug (local/run.bash:75-105): builds a debug image and starts the service with a Delve entrypoint (dlv --listen=:40000 --headless … exec /server) — attach your IDE to localhost:40000. Migration (local/run.bash:142-153): brings up docker-compose.migration.yaml, waits for it, then starts the service — the forward-only migrations from the Postgres course, run as one-shot containers. Stop also removes the kafka/postgres volumes (:190-191) — a clean slate, but you lose local data.

The same idea on the kind stack

The kind + Skaffold stack has its own reload path (you won't use it as often): ./deployments/sk.bash -b bob builds and injects the binary via deployments/reload.bash, while ./deployments/sk.bash -s bob does a skaffold run then kubectl rollout restart deploy/bob (deployments/sk.bash:138-167). Note the special cases: tom and conversationmgmt are StatefulSets, and gandalf restarts two deployments. Same goal — get your new code running — one in containers, one in real pods.

The whole loop, one sentence Edit Go → run.bash start -s <svc> compiles and docker cps the binary into the running container → modd restarts it. That's the inner loop; you only do a full run.bash (or sk.bash) when configs, dependencies, or the image itself change.
Read this next

In-repo: local/run.bash + the /run-local command

The script is the source of truth; the slash-command doc is the human reference for every mode.

local/run.bash (start/stop/restart/bdd/cron)
.claude/commands/run-local.md (full CLI reference)
skaffold.dev — Continuous development (skaffold dev)

Check yourself (from memory)

Q1. run.bash start -s bob is fast because it…

docker cp build/server → local-bob-1:/server; modd restarts the process. No image rebuild.

Q2. What restarts the process after the binary is copied in?

modd (baked into the image, Lesson 2) watches /server and restarts it when the binary changes.

Q3. To attach a debugger, you'd start the service with…

Debug mode runs /server under dlv --listen=:40000 --headless; attach your IDE to that port.
Trace run.bash start -s bob, and name the other modes.
recall, then click to reveal
NORMAL: build-code-golang.bash compiles build/server, then docker cp build/server local-bob-1:/server (run.bash:161); MODD (image entrypoint) restarts the process — no image rebuild, seconds. FLAGS: -b false skip image rebuild (copy only); -m migration run migration container then start; -m debug Delve on :40000; stop tears down all + drops kafka/postgres volumes; bdd -s runs BDD in local-gandalf-1. KIND stack equivalent: sk.bash -b (reload binary) / sk.bash -s (skaffold run + kubectl rollout restart; tom/conversationmgmt are StatefulSets). Full run.bash only when configs/deps/image change.
🎓 Course complete — all 8 lessons Part 1: what a container is, images/layers/Dockerfiles, running containers, Docker Compose. Part 2: the env × org matrix, the two local stacks, Skaffold's build/render/deploy, and the hot-swap dev loop. You now have the foundation for the whole deployment track — Course 2 (Kubernetes) picks up exactly where the kind + Skaffold stack leaves off.
Ready for Course 2 (Kubernetes)? Or — six full courses built and still no retention check — let me run a mock interview on containers & local dev first and record where you're solid. Ask me.

1. In-repo: local/run.bash:75-105,142-163,190-191, deployments/sk.bash:138-167; Skaffold — continuous development.