Score: Define Your Workload Once, Run Anywhere

Why it exists

Modern deployments force developers to become experts in multiple infrastructure tools, leading to high cognitive load. Maintaining separate configuration files for local (e.g., Docker Compose) and remote (e.g., Kubernetes) environments causes config drift and YAML bloat. Score was created to provide a single source of truth for a workload's requirements.

The mental model

Think of Score as a universal remote for your application's environment. You write a single score.yaml file that declaratively states your workload's needs: which ports to open, what resources it depends on (like a database), and what environment variables it requires. The Score CLI then translates this single file into the specific language of your target platform.

How it works

The process has four main steps. First, you create a score.yaml file in your workload's repository. Second, you install a Score Implementation CLI for your target platform, such as score-compose or score-k8s. Third, you run the CLI to generate a native configuration file, like score-compose generate which outputs a docker-compose.yaml. Finally, you use the platform's standard tools, like docker-compose up or kubectl apply, to run your workload using the generated file.

When to use it

Use Score when you want to ensure configuration consistency for a service that runs in multiple environments, like a developer's local machine and a production Kubernetes cluster. It's ideal for teams aiming to reduce developer toil and establish a single source of truth for how a service should be configured, regardless of where it runs.

When not to use it

Score's abstraction might be limiting if your workload requires complex, platform-specific features that are not easily described in a generic spec. While Score offers escape hatches for platform-specific extensions, overusing them defeats the purpose. For projects that will only ever target a single, simple platform, the extra layer of abstraction may be unnecessary overhead.

One canonical example

A score.yaml file declaratively defines a workload's needs. For a web service, it might specify a container image, expose port 8000, and declare a dependency on a PostgreSQL database resource named db. It can then use details from that resource, like ${resources.db.password}, to construct a connection string, all without knowing how the db resource will be provisioned in the target environment.