Docker adds agent-focused building blocks to Compose
Docker announced agent-focused building blocks for Docker Compose, describing a compose.yaml-based way to define models, agents, and MCP-compatible tools together. The company named integrations and examples involving several agent frameworks, with local development and cloud deployment integrations. Compose provides a packaging layer for these multi-service agent applications.
By Hypler editorial team ยท Source: Docker.
Original source date: .
Hypler publication: . Hypler updated: .
Topics: Docker, Compose, agents, MCP
Engineering relevance
Declarative packaging can make an agent stack easier to reproduce, inspect, and test across environments. It also concentrates risk in configuration: model endpoints, tool containers, environment variables, network rules, and volumes need review as a system. A portable compose file is useful operational evidence only when its dependencies, permissions, and validation outcomes are documented.
Source record: Compose definitions for agent stacks
On July 10, 2025, Docker announced agent-focused building blocks for Docker Compose. The article described using a compose.yaml file to define open models, agents, and MCP-compatible tools, then running the stack with docker compose up. Docker listed examples involving LangGraph, Embabel, Vercel AI SDK, Spring AI, CrewAI, Google's ADK, and Agno. It also described integrations with Docker's MCP Catalog and Model Runner, plus cloud deployment integrations for Google Cloud Run and Microsoft Azure Container Apps. The source positions Compose as a declarative packaging layer for agentic applications.
Engineering guidance: make the stack topology reviewable
A Compose file should describe a complete, reviewable topology: services, images, commands, ports, networks, volumes, environment variables, health checks, resource limits, dependency order, and profiles. Assign every service a clear role such as model endpoint, agent runtime, retrieval index, MCP server, gateway, or observability collector. Pin production-intended images by digest and build reproducible local images from declared source revisions. Use named networks to express intended communication paths, then remove default connectivity that a service does not need. The resulting manifest becomes both an executable definition and a concrete artifact for design, security, and operations review.
Configuration should separate environments without hiding drift
Keep environment-specific values in reviewed configuration layers rather than copying whole Compose files. A base topology can define service relationships and schemas; environment overlays can supply hostnames, image digests, resource limits, and references to secret stores. Generate or inspect the resolved configuration in CI so a reviewer can compare the actual development, test, and release topology. Track changes to ports, mounts, capabilities, networks, and credentials as first-class diffs. This approach preserves the portability benefits of declarative packaging while keeping each environment's operational boundary visible.
Hypothetical implementation: a local retrieval-and-tool stack
Consider a hypothetical local stack with an agent runtime, a read-only retrieval service, an MCP gateway, and a documentation-search server. The compose.yaml file pins each image, places the agent behind the gateway, exposes the retrieval service only on an internal network, and mounts synthetic fixtures read-only. The agent receives a task request and can call one search tool through the gateway; it has no credential for source writes or deployment. Health checks wait for the index and gateway before the agent starts. A test profile runs the same topology with deterministic fixtures and records tool calls for inspection.
Secrets, storage, and networks need explicit ownership
Reference secrets through the platform's designated secret mechanism or runtime injection path, never through image layers or committed environment files. Map every volume to its data owner, retention rule, backup requirement, and permitted writer. Define outbound network destinations for services that call model APIs, identity providers, package registries, or external tools, then validate those paths at runtime. Run processes with the lowest practical privileges and use read-only filesystems where a service does not need to write. These controls keep a convenient multi-service definition from silently widening access to data, hosts, or credentials.
Validate the resolved stack and its failure paths
Validation should inspect the resolved Compose configuration and run the named services together. Cover clean startup, health-check failure, unavailable model endpoint, invalid tool response, missing secret, denied network route, corrupted retrieval index, service restart, and duplicate task request. Confirm that logs carry service identity and correlation identifiers across the agent, gateway, and tool server. Measure startup time, memory, CPU, request latency, and outcome categories under representative fixtures. A release decision can then rely on an identified Compose revision, pinned artifacts, and evidence from the topology that users will actually run.
Compose profiles can make test intent explicit. A minimal profile can run contract fixtures against mocks, an integration profile can start real local dependencies, and a release profile can resolve the same service graph with production-intended image digests and external references. Keep profile selection in the validation receipt so a passing unit-focused run is never mistaken for a full integration result. Generate an artifact containing the resolved file, image digests, profile name, environment identifiers, and test outputs. That artifact lets another operator reproduce the exact stack without reconstructing hidden command-line state.
Original source
Related links
Historical source briefing with Hypler engineering analysis. Source details reflect the original publication date; implementation examples are hypothetical.