Docker-Compose

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.

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.