Lesson 11 · Senior containers & local dev

Fast local inner loops

Rebuild vs hot-swap vs restart vs redeploy — and why a good local loop is really about skipping the expensive step you do not need.

Your win: explain why this repo hot-swaps binaries into running containers, when that is better than image rebuilds, and how to choose the right loop for the change you just made.

In plain English Plain English: a fast inner loop is about avoiding the expensive step you do not need for the current change.

The question behind every local-dev loop

The question is not “what is the fastest command?” The question is “what layer of runtime reality changed, and what is the cheapest way to make that layer true again?”

That is the senior framing. If you changed Go code, host-compile plus binary copy might be enough. If you changed the image, the entrypoint, or rendered config, that is no longer enough. The right loop depends on what actually changed.

The loop rule Choose the cheapest path that still makes the changed layer true at runtime.

Why this repo chose hot-swap for the normal path

run.bash start -s <svc> compiles on the host and docker cps the fresh binary into the running container. modd notices and restarts /server.

That is faster than image rebuilds because the workflow avoids rebuilding layers, re-running Compose bring-up, and redoing setup that did not change. The repo is not “fast at rebuilding.” It is smart about avoiding rebuilds during the common case.

Anchor — the core fast path local/run.bash shows the hot-swap flow directly: build the Go binary, copy /server, and let the running container update in place. The same script also exposes migration mode and debug mode, which are different loop shapes for different needs.

Why one loop is never enough

This is the part people often miss. A mature repo usually has more than one local path because different changes live at different layers. Normal code change? Hot-swap. Need migrations first? Migration mode. Need a debugger? Debug mode. Need higher-fidelity cluster behavior? Switch to the kind stack.

That is not duplication. That is just the repo admitting that “local development” is not one activity.

Common mistake Treating one fast loop as universally correct. If you changed the image, the entrypoint, or rendered config, hot-swap alone may leave you testing the wrong runtime reality.
Read this next

The local script is the truth

The repo script is more valuable than a generic blog post here because it names the exact modes this team really uses — and that is what you want to internalize.

→ local/run.bash
→ deployments/sk.bash

Check yourself (from memory)

Q1. The right local loop should usually be…

The goal is faithful feedback with minimal unnecessary cost.
Why is hot-swap the normal path in this repo?
recall, then click to reveal
Because many day-to-day backend changes only affect the compiled service binary, so host-compile plus docker cp avoids unnecessary image rebuild and stack-restart work.
Want a decision table for “code change vs config change vs image change”? Ask me.

Sources. In-repo local and deployment scripts.