A Dockerized backend for full-stack context engineering
Running the database, Mailpit, and the whole backend in Docker gives me and my AI agent one real, reproducible stack to work against. Add Chrome DevTools MCP and the loop is closed.
I have written about context engineering, giving an AI agent the whole stack to work with. A big part of “the whole stack” is the backend and its dependencies, and the cleanest way I have found to make those real, reproducible, and safe is Docker. Add Chrome DevTools MCP on the frontend side and the agent can see the entire system, end to end.
One command brings the whole backend up
The backend and its services live in Docker Compose: the FastAPI app, PostgreSQL,
and Mailpit for email. Run docker compose up and the whole environment is
running, identical on my machine, a teammate’s, and CI. There is no “install
Postgres, match the version, seed it by hand” ritual. A reproducible environment
is the foundation everything else sits on.
Postgres in a container, seeded and disposable
The database runs in a container with a pinned version and a seed script, so every environment starts from the same known state. If I want a clean slate, I tear it down and bring it back in seconds. That is what makes working against real data safe: it is real Postgres, but it is disposable and reproducible, not a precious shared instance I am afraid to touch.
Mailpit, so nothing real gets sent
Outbound email points at Mailpit instead of a real provider. It speaks SMTP like a normal mail server but captures everything in a local inbox with a web UI, so I can see exactly what the app would have sent without a single real message going out. Other outbound notifications get the same treatment: caught locally, never delivered. Testing a flow that sends things is suddenly safe and fully inspectable.
Why this is context engineering, not just DevOps
Here is the part that ties back to working with an AI agent. A Dockerized backend is not only convenient for me, it is context for the agent. It can bring the stack up, hit the real API, watch a row land in Postgres, and confirm the right email showed up in Mailpit, all in an environment that behaves the same way every time. An agent reasoning about a running system beats one guessing from source, and Docker is what makes that running system cheap and repeatable.
Chrome DevTools MCP closes the frontend loop
The backend is only one half. On the frontend, Chrome DevTools MCP lets the agent drive a real browser: inspect the DOM, read the console, watch network requests, capture a screenshot, profile performance. So the agent can trigger a flow in the UI, follow the request to the Dockerized backend, confirm the database changed and the email landed in Mailpit, then verify what actually rendered in the browser. That is the whole loop, visible to the agent and not just to me.
The payoff
Reproducible backend, safe side effects, and eyes on the frontend. For me it means less setup and fewer “works on my machine” surprises. For the agent it means a real system to act on and observe instead of a pile of files to guess about. Full-stack engineering gets easier for both of us when the entire stack is one command away and everything it does is inspectable.