Docker

Package the agent stack with one multi-target Dockerfile, one Compose file, and a dev.sh script with health gates locally.

Revised, split, and expanded — The two halves of this article are now separate chapters in the MAF v1: Python and .NET series: the auth + hardening half is covered by MAF v1 — 20c production hardening (with the password reset, refresh-token rotation, and graceful secret rotation that the original missed), and the deployment half is covered by MAF v1 — 25 deployment (with the .NET twin Dockerfile and a dev.sh that polls instead of sleeping). The architecture below is still the canonical reference for the combined story.

Docker shipped a set of tools that let a platform team decide exactly which Model Context Protocol servers developers can run: a catalog format, an open-source Gateway, and a Toolkit built into Docker Desktop. The official catalog carries 220+ containerized MCP servers, and you can fork it, trim it, or build a private catalog that points at images in your own registry.

At some point I had three side projects each talking to a different LLM provider, with API keys pasted into three .env files and three slightly different client wrappers. Swapping GPT-4o for Claude in any of them meant editing code. That is a silly amount of friction for what is, underneath, the same chat-completion call, so I put a LiteLLM proxy in front of everything and never went back.

Introduction # Nothing kills momentum on a new project like cloning the repo, running docker compose up, and landing on an empty database. No roles, no permissions, no login, so nothing works until someone reads the wiki and hand-runs a SQL script. On the Contact Management Application I wanted docker compose up to be the whole setup: containers come up, the schema seeds itself, and you can log in.

Getting the Contact Management Application running used to mean installing the .NET SDK, Node, and a local SQL Server, then hoping the versions matched mine. That is three toolchains of setup before anyone sees a login page. Containerizing the stack collapses all of it into docker-compose up --build: the API, the Angular frontend, SQL Server, and an nginx load balancer come up together, wired the same way on every machine. This post walks through the Dockerfiles and compose files that make that work, including the parts I would do differently today.

A custom image that only exists on your laptop is not shipped; it is a local experiment. The moment a teammate or a server needs to run it, the image has to live in a registry. Docker Hub is the one most people start with, and the push workflow is the same shape you will later use against Azure Container Registry or Amazon ECR, so it is worth doing once by hand before automating it. This post walks through that manual path with a small nginx-based image.

In the previous article I built a custom nginx image and pushed it to Docker Hub by hand: build, tag, login, push. That works exactly once. The second time you forget the tag, the third time a teammate pushes from a laptop with a stale base image, and soon nobody can say which commit produced the image running in production. The fix is boring and reliable: let GitHub Actions do the build and push on every commit to master.