This article is based on an interview originally published on InfoQ with Justin Cormack, security lead at Docker, about the Compose Specification community.
Background: Why a Compose Specification?
Docker Compose started as a single Python-based tool with one authoritative implementation. Over time, multiple independent implementations emerged — each trying to replicate Compose behaviour on different platforms such as Kubernetes and AWS ECS. Those implementations had to copy what Docker did without having any formal influence over the direction of the tool, and without a shared definition of what “correct” behaviour actually looks like.
To address this fragmentation, Docker released an open Compose Specification and launched a community around it. The goal is to give platform implementers, developers, and operators a shared, vendor-neutral definition of the Compose file format — and a process for evolving it together.
Interview: Justin Cormack on the Compose Specification Community
InfoQ spoke with Justin Cormack, security lead at Docker, to learn more about the motivation behind the spec, its current state, and where it is headed.
What problem does the Compose Specification solve?
Cormack: Originally there was only one implementation — Docker Compose in Python. But additional implementations appeared that looked at what Docker Compose does and tried to replicate as much as possible. The problem is that platforms sometimes do things differently. Even within Docker itself there were multiple implementations: one for Kubernetes, one for Swarm, and others. Each had to copy our behaviour and then adapt it, but they had no formal input into how Docker Compose itself evolved.
The Compose Specification is designed to let people use Compose across different platforms and to make any new features first-class citizens of the spec, giving the community real influence over how it progresses. We knew there were problems running Compose on Kubernetes because it handles networks and volumes differently. AWS ECS has its own implementation to integrate with other AWS services. The best path forward was an open specification that covers platforms beyond Docker Swarm or Docker Desktop.
What is the current state of the spec?
Cormack: It is not a complete specification yet. At this stage it defines which parameters exist, which sections are valid in a Compose YAML file, and which parts are optional — because not all existing implementations support every feature. There is also a reference for implementing tests.
The community holds regular meetings to discuss open issues and decide what to fix. One gap we acknowledge is a full conformance test suite — a defined set of tests that would let an implementer prove their tool is a valid Compose implementation. That is something we want to build in the future.
In the short term we are also looking at how platform-specific features — such as Kubernetes-specific networking or ECS task definitions — can be expressed as custom extensions inside a Compose file without breaking portability. The plan is to later evaluate which of those extensions make sense as general cross-platform features.
Can Compose evolve beyond developer workflows into production use?
Cormack: There are currently two broad usage patterns. Some teams use Compose purely for local development and testing — the compose file never reaches production. Other teams have a workflow where developers write Compose files that a separate operations team then uses as a reference when writing a corresponding infrastructure-as-code file, but the two are not automatically kept in sync.
We are not trying to dictate how or where people use Compose. When we were shaping the spec we looked at adoption data: on GitHub alone there were around 700,000 Docker Compose files, and most of them are not used for production deployments. They typically define how to spin up a system quickly for development or demonstration purposes.
My view is that Compose should remain focused on developer concerns. Operational concerns — how to run systems reliably in production — belong elsewhere. Your Compose file would describe the developer-facing pieces of a system, not the complete production configuration. That separation of concerns keeps Compose approachable and focused.
What is on the roadmap?
Cormack: We do not have a formal roadmap. Part of the intent is to let the community drive direction and fix real problems early. That said, there are things I personally would like to see.
One is moving away from requiring an explicit version number in the Compose file. Instead of pinning to a version, I would prefer a feature-driven model: the tooling looks at which features you are using and tells you whether they are supported on your target platform. If a feature is not supported, it should return a clear, actionable message — not a cryptic error.
Key Takeaways
- Fragmentation problem: Multiple Compose implementations existed without a shared formal definition, leading to inconsistent behaviour across platforms.
- Open specification: The Compose Specification defines the YAML schema, optional fields, and a test reference — but is not yet a complete behavioural spec.
- Conformance tests: A full conformance test suite is planned but not yet available.
- Platform extensions: Short-term work focuses on a safe way to express platform-specific features (e.g., ECS, Kubernetes) inside Compose files.
- Developer focus: Compose is intended to remain a developer tool. Production concerns should live in a separate layer.
- Community-driven roadmap: There is no fixed roadmap; the community and real-world problem reports shape priorities.
- Feature-driven versioning: A future goal is to replace version-pinned Compose files with a feature-detection model.
Further Reading
The Compose Specification is maintained as an open project. Developers and platform implementers interested in contributing can follow the community discussions and open issues in the specification repository to understand current priorities and how to get involved.