docker/compose-for-agents: Twelve Agent Stacks You Run With docker compose up

What the repository actually contains

This is a demo collection, not a package you install. The README presents a classification table of twelve entries, each pointing at a subdirectory (./a2a, ./agno, ./vercel, ./crew-ai, ./adk, ./adk-cerebras, ./langgraph, ./embabel, ./spring-ai, ./adk-sock-shop, ./langchaingo, ./minions) and at a compose file. The frameworks differ widely: Google's ADK appears three times, alongside LangGraph, Langchaingo, CrewAI, Agno, Embabel, Spring AI and the Vercel AI SDK. The models column mixes locally served weights (qwen3, llama3.2, gemma3-qat, gemma3, a 23M MiniLM embedding model) with remote APIs, and the MCPs column lists duckduckgo, github-official, wikipedia-mcp, brave, postgres, MongoDB, curl, weather, google-maps, airbnb and resend. The primary language is TypeScript, but the table makes clear the demos are polyglot in practice: the ADK and Spring AI entries are Python and Java projects respectively, and one ADK variant is described as Golang Experts. The repository is licensed Apache-2.0 OR MIT, with the README noting that individual examples may carry their own LICENSE files reflecting third-party requirements.

The problem it solves: the wiring, not the agent

Writing an agent loop is not the hard part any more. Getting a model server, an agent runtime, and one or more MCP tool servers onto the same network with the right tokens and the right base URLs is where an afternoon disappears. Each demo here is a working answer to that, expressed as a Compose file. The audience is an engineer who has picked a framework and now needs to see it talking to a real tool server, or an engineer comparing frameworks who wants the same problem (fact checking, SQL queries, travel planning) solved several ways. It is not aimed at someone who wants a supported SDK. There are no releases retrieved for this repository, so there is no version to pin and no changelog to read.

How a demo is wired together

The architecture visible in the README is uniform across the table. A Compose project defines services for the agent runtime, for the model, and for each MCP server the agent calls. Docker Model Runner supplies local models, which is why the prerequisites talk about GPU support and drivers rather than about Python wheels. The agent reaches the model through the runner and reaches tools through MCP, and Compose puts them on one network so no host port juggling is needed. The README's own two-step description is: change directory to the root of the demo project, create a .mcp.env file from mcp.env.example (if it exists, otherwise the demo needs no secrets), then run docker compose up --build. The conditional in that sentence matters. Demos whose MCP column is empty, such as the ADK and Cerebras Golang Experts entry, have nothing to authenticate. Demos wired to github-official, brave, resend or google-maps do.

Swapping the local model for OpenAI

The one cross-cutting configuration in the README is the OpenAI override. Write a file named secret.openai-api-key containing the key, then start the project with an additional compose file: docker compose -f compose.yaml -f compose.openai.yaml up. This is the standard Compose override pattern, and it is the clearest sign that these demos are meant to be read and edited rather than consumed. The override only exists where the demo ships a compose.openai.yaml, and the README does not enumerate which ones do. The classification table lists OpenAI only for the A2A Multi-Agent Fact Checker, so a reader who wants OpenAI elsewhere should expect to write the override themselves. Note also that the plain command in the setup steps includes --build while the OpenAI command does not, which is a small inconsistency in the instructions rather than a meaningful difference.

GPU, Docker Offload, and the Compose version floor

The prerequisites are the most restrictive part of the repository and the part most likely to stop an evaluation cold. Docker Desktop 4.43.0 or later, or Docker Engine, is required. A laptop or workstation with a GPU is stated as the norm for running open models locally, with Docker Offload named as the alternative when there is no GPU. On Linux with Docker Engine, or Windows with Docker Desktop, the README points at the Docker Model Runner requirements and specifically at GPU support being enabled with the necessary drivers installed. On Linux with Docker Engine there is also a hard version floor: Docker Compose 2.38.1 or later. None of this is optional scaffolding. An agent demo that cannot start its model server has nothing to demonstrate, so a CI runner without GPU passthrough is the wrong place for these projects unless Offload is in play.

Where the collection is thin

Two things are missing that a reader will look for immediately. The first is per-demo documentation. The README gives one table and one set of global instructions; the detail lives in each subdirectory, and the table itself is inconsistent about where compose files live, with some links pointing into this repository and others pointing at external repositories such as scira-mcp-chat, compose-agents-demo, embabel/travel-planner-agent and HazyResearch/minions. A demo whose compose file lives in someone else's repository can change without anything in this repository changing. The second is verification. There are no releases and no retrieved version tags, so there is nothing to pin against and no signal about which demos are actively maintained versus illustrative. The README also does not say which demos have been checked against the current Docker Model Runner requirements. Treat the table as a map of what exists, not as a support matrix.

How this differs from a framework's own examples

CrewAI, LangGraph and Google's ADK each publish their own examples, and those examples assume you have already solved model hosting and tool connectivity. The difference here is that the model server and the MCP servers are part of the same Compose project, so the example is runnable end to end. The cost of that convenience is coupling: the demos are shaped by Docker Model Runner and by Compose conventions, so a team deploying agents to Kubernetes or to a serverless platform gets less direct reuse. A framework's own quickstart will be closer to that team's target environment. The MinionS entry, described as Cost-Efficient Local-Remote Collaboration with qwen3 local and gpt-4o remote, is the one case where the split between local and remote is itself the subject of the demo rather than an implementation detail.

Licensing and the cost of keeping a copy

The repository is dual-licensed under Apache-2.0 or MIT at your choice for Docker's contributions, expressed as SPDX-License-Identifier: Apache-2.0 OR MIT. The README then warns that each example may have its own LICENSE file reflecting third-party requirements, and that those must be respected. That distinction matters if you copy a demo into a product: the top-level grant covers Docker's work, not necessarily the vendored framework code, the model weights, or the MCP servers the compose file pulls. Read the LICENSE inside the specific demo directory before reuse. On maintenance, the honest position is that there is nothing to upgrade. No releases were retrieved, so there is no tag to bump; you track the main branch or you fork the one demo you care about. The upgrade cost sits with the images and models the compose file references, and those move independently of this repository.

Editorial conclusion

Adopt this repository if you already run Docker Desktop or Engine with GPU support and want a working Compose file to copy from rather than a framework to learn. Skip it if you need a supported library, a versioned release, or a deployment that runs without a GPU or Docker Offload. Before copying anything, check the compose file in the specific demo directory for its model runner service, whether an mcp.env.example exists, and whether the example ships its own LICENSE.

Official sources

1. docker/compose-for-agents on GitHub
2. Issues
3. License: Apache-2.0
4. README