Why Is It Called "Score"?
The name is intentional. Think of a musical score — the written sheet music a composer produces.
- The composer writes the score once. It describes the music abstractly: notes, tempo, dynamics.
- A pianist reads that score and plays it on a piano (your laptop, Docker Compose).
- An orchestra reads the same score and performs it in a concert hall (production Kubernetes).
The music — the workload's intent — is identical in both cases. The instrumentation changes completely. No one expects the composer to rewrite the score for each instrument. Score (the tool) applies this same principle to infrastructure.
The Two Components
1. The Specification (score.yaml)
This is the developer's artifact. It is deliberately abstract. It describes:
- What containers to run and what images to use.
- What ports the service exposes.
- What environment variables the containers need.
- What external resources the workload depends on (databases, caches, queues) — by type, not by address.
Critically, score.yaml contains no environment-specific values. No IP addresses. No cloud-provider-specific resource ARNs. No cluster names. It is as portable as source code.
2. The Implementation (The Translator CLI)
This is the platform team's artifact. It is a CLI tool that:
1. Reads the score.yaml.
2. Reads environment-specific configuration provided by the platform team.
3. Resolves abstract resource requests to concrete infrastructure.
4. Outputs a platform-native configuration file.
The two official implementations are:
- score-compose: Generates docker-compose.yaml for local development.
- score-k8s: Generates Kubernetes manifests (Deployments, Services, ConfigMaps, etc.).
The Score specification is open. Any team can write a custom implementation targeting any platform — Nomad, ECS, Cloud Run, or an internal PaaS.