A community talk for Docker Kuala Lumpur about using Docker Model Runner and local AI tooling without turning developer workflows into security debt.
The session covered the limits of traditional runners, the cost and privacy tradeoffs of hosted AI workflows, and how containerized local models can make experimentation easier to reproduce.
What I Covered
The talk started with a practical problem: AI-assisted development is useful, but the default path often sends code, logs, or context into external services before a team has really decided whether that is acceptable.
I framed Docker Model Runner as a way to make local AI workflows more reproducible. If a model, prompt, and runtime can be packaged and run consistently, teams can experiment with review bots, summarizers, and code assistants without immediately depending on a hosted AI API.
Main Ideas
The first idea was cost control. Local models are not free, but they can make repeated experiments cheaper and easier to reason about compared with remote calls for every review or summarization task.
The second idea was privacy. Running closer to the developer machine or controlled infrastructure gives teams more room to redact, inspect, and decide what leaves the boundary.
The third idea was workflow design. A useful AI review loop should be scoped: read the diff, explain risk, suggest tests, and leave the final judgment with the engineer. It should not pretend to be a senior reviewer just because it can produce confident text.
What I Would Improve Next
If I give this session again, I would add a deeper live demo: a small repository, a local model review pass, a GitHub Actions comparison, and a discussion of where the approach breaks down. The strongest part of the topic is not the tool itself; it is the engineering discipline around controlled experimentation.