A container is an isolated environment for running an application with its dependencies while sharing the host operating system kernel. For an agent, it provides a way to run a backend service separately from the browser application that calls it. That separation matters when the agent needs server-side tools, handles long-running work, or should not expose its prompts in the browser. section 8.1 section 8.6
Think of three choices: embed an agent in a web application, put it behind an API, or run agent services as containerized microservices. A focused agent API is a good container candidate: other services can call it, and the agent can be upgraded or replaced without rebuilding the whole application. A browser-based agent can also use containerized agents as tools through an API or MCP server. Usually one agent runs per container, though a multi-agent workflow can be packaged together. section 8.1 section 8.2
To run a small agent API locally:
- Put a Dockerfile beside the application. Specify a Python base image, install requirements, copy the code, and set a command that starts the API server. section 8.2.1
- With Docker Desktop running, build an image using `docker build -t image-generator:latest .`. The image is what Docker uses to create a running container. section 8.2.1
- Run it with `docker run --rm -p 8000:8000 -e OPENAI_API_KEY="your_key_here" image-generator:latest`. Test the API on local port 8000; stop the container when finished. The `--rm` option removes it after it stops. section 8.2.1
Listing 8.4 Dockerfile and generation prompt
{copy the Python web API or MCP code above}
Prompt: Generate a Dockerfile that containerizes the above application. The above application is called 02_app.py. #1
FROM python:3.11-slim #2
ENV PYTHONDONTWRITEBYTECODE=1 \
PYTHONUNBUFFERED=1 \
PORT=8000
WORKDIR /app
RUN apt-get update && apt-get install -y --no-install-recommends \
build-essential curl ca-certificates && \
rm -rf /var/lib/apt/lists/* #3
COPY requirements.txt /app/requirements.txt #4
RUN if [ -f /app/requirements.txt ]; then \
pip install --no-cache-dir -r /app/requirements.txt; \
else \
pip install --no-cache-dir "uvicorn[standard]" fastapi; \
fi
COPY . /app
EXPOSE ${PORT} #5
CMD ["sh", "-c", "uvicorn 02_app:app --host 0.0.0.0 --port ${PORT}"]
The Dockerfile shows the complete progression from a Python base image and installed dependencies to the command that starts the agent API. section 8.2.1
For several services, Docker Compose replaces separate run commands with one YAML definition. Each service represents a container; the example defines a web service plus image and web agents, with ports, environment settings, and dependencies. After setting the API key in `.env`, `docker compose up --build` starts the stack and `docker compose down` stops it. Check the app and Compose logs to confirm requests reach the intended agent. section 8.2.2 section 8.5
Listing 8.5 docker-compose.yaml
version: "3.9" #1
services:
web: #2
build: ./web
container_name: realtime-voice-web
ports: ["8000:8000"]
environment: #3
OPENAI_API_KEY: ${OPENAI_API_KEY}
DEFAULT_MODEL: ${DEFAULT_MODEL:-gpt-4o-realtime-preview-2025-06-03}
DEFAULT_VOICE: ${DEFAULT_VOICE:-alloy}
ALLOWED_ORIGINS: ${ALLOWED_ORIGINS:-*}
depends_on:
- image_agent
- web_agent
image_agent: #4
build: ./image_agent
container_name: realtime-image-agent
ports: ["8001:8000"]
environment:
OPENAI_API_KEY: ${OPENAI_API_KEY}
web_agent: #5
build: ./web_agent
container_name: realtime-web-agent
ports: ["8002:8000"]
environment:
OPENAI_API_KEY: ${OPENAI_API_KEY}
WEB_AGENT_MODEL: ${WEB_AGENT_MODEL:-gpt-5-mini}
The Compose file makes the three service boundaries, port mappings, environment variables, and startup dependencies inspectable. section 8.2.2
Before production use, review and trim a generated Docker image rather than accepting it unchanged. Local Docker Desktop demonstrates the pattern; larger deployments may use Kubernetes or cloud container hosting, but those deployment procedures are not developed here. section 8.2.1 section 8.2
