Lesson 9 · Senior containers & local dev

Image strategy and entrypoints

Why Dockerfile.development is really a workflow design document — not just a build recipe.

Your win: explain why this repo has no-op, developer, and developer-debug paths, and why “one binary, many services” is a local-dev strategy as much as an image strategy.

In plain English Plain English: the Dockerfile is not only about producing an image; it quietly decides how fast, debuggable, and flexible your whole local workflow will feel.

The beginner reading vs the senior reading

The beginner reading of a Dockerfile is: “this is how the image gets built.” That is true, but incomplete. The senior reading is: “this file is also deciding what kinds of developer loops are cheap, what kinds of debugging are possible, and how much one image can be reused without becoming a mess.”

That is the frame you want for this lesson. Dockerfile.development is not just the thing that turns code into a runnable image. It is one of the quiet reasons the repo’s local loop feels the way it does.

The rule to memorise Image strategy is workflow strategy. If you understand the stages and entrypoints, you understand why the local loop behaves the way it does.

Why one image has to serve several jobs

This repo is not building a tiny single-purpose image for one microservice and calling it a day. It is building a local developer runtime that has to support normal starts, hot-swap reloads, BDD tooling, migrations, and debug sessions. Once you see that, the multiple stages stop looking decorative.

The question changes from “why is this Dockerfile a bit bigger?” to “what different workflows is this Dockerfile trying to make practical?” That is a much more senior question.

What the stages are really doing

no-op exists so a container can start with modd and wait for a fresh binary to be copied in. developer is the real runtime image with /server, migrations, features, and helper assets. developer-debug layers Delve on top for debug sessions.

Same repo, same codebase, different developer workflows encoded as image shapes. That is the tone shift from basic Docker knowledge to workflow design judgment.

Anchor — where this is visible local/Dockerfile.development shows the whole story plainly: download-modd, no-op, developer, and developer-debug, plus the copy of one build/server binary and the different entrypoint expectations around it.

The deeper repo idea This is also where the repo’s “one binary, many services” model shows up in container form. The image does not hard-code “this is bob” or “this is fink.” The runtime command and mounted config finish that decision later.

Common mistake Thinking the Dockerfile only exists to make the image “run,” while missing that it also determines whether local reload, debugging, and one-binary-many-services remain practical.

Docker multi-stage builds + the repo Dockerfile

The official multi-stage doc gives the generic pattern. The repo Dockerfile shows the local-dev-specific adaptation — and that contrast is exactly what makes the lesson stick.

→ Docker — Multi-stage builds
→ local/Dockerfile.development

Check yourself (from memory)

Q1. The biggest reason this Dockerfile has multiple runtime-oriented stages is…

The stages reflect different developer workflows, not just generic build neatness.

Why is image strategy also workflow strategy in this repo?

recall, then click to reveal

Because the Dockerfile stages and entrypoints decide whether the local stack can hot-swap binaries, run debug sessions, reuse one image for many services, and keep the inner loop fast.

Want me to compare no-op vs developer vs developer-debug line by line? Ask me.

Sources. Docker multi-stage docs; in-repo Dockerfile.