CUE
By CUE Labs
CUE is a data validation and configuration language that unifies schema definition, data validation, and value generation into a single formalism based on order-independent constraint unification rather than templating or inheritance. It…
Definition
CUE is a data validation and configuration language that unifies schema definition, data validation, and value generation into a single formalism based on order-independent constraint unification rather than templating or inheritance. It is used to describe and validate configuration for systems like Kubernetes, APIs, and infrastructure tooling, letting teams express what a valid configuration looks like and derive concrete values from that description rather than writing separate schema and data files that can drift apart.
Overview
Configuration for modern infrastructure tends to accumulate in layers: a base template, environment-specific overrides, and a validation schema checked separately, usually in JSON Schema or a hand-rolled linter. This separation is a common source of bugs, because the schema and the actual configuration are maintained independently and nothing forces them to agree. CUE was built to close that gap by treating schemas and data as the same kind of value, expressed in the same language, so that validation is not a separate pass but a natural consequence of how values combine. The mechanism underneath CUE is unification, a concept borrowed from logic programming: every value in CUE is a constraint, and combining two CUE files or two values means unifying their constraints into a single, more specific result. If two constraints conflict, unification fails and CUE reports an error at that point, rather than silently letting a later value overwrite an earlier one as most templating systems do. This makes CUE order-independent, which is different from formats like Helm's Go templates, where the final result depends on the sequence in which fragments are merged. Because a schema is just a broader constraint and concrete data is a narrower one, defining a type and validating an instance against it are the same unification operation. Among configuration languages, CUE sits closer to Dhall than to YAML or JSON in that it treats correctness as a first-class concern rather than an afterthought, but CUE distinguishes itself from Dhall by using unification instead of a total functional language with imports, and it is explicitly designed to layer on top of existing JSON and YAML rather than replace them outright, exporting to those formats as a compilation target. It also differs from Starlark, which favors executable, Python-like build logic, by staying purely declarative with no imperative control flow. In practice, CUE is most visible inside the Kubernetes ecosystem, where tools use it to generate and validate manifests, and inside API definition workflows where teams want a single source of truth that produces OpenAPI specifications, Go structs, and documentation from one CUE definition. It is also used standalone via its command-line tool to validate JSON or YAML files against a CUE schema in continuous-integration pipelines, catching malformed configuration before it reaches a cluster or a downstream service. The main trade-off is a steeper learning curve: unification is a genuinely different mental model from the merge-and-override semantics most engineers already know from YAML anchors or Helm values files, and error messages when two constraints conflict can be harder to trace back to their source in large, deeply layered configurations. CUE's tooling ecosystem is also smaller than that of established formats like JSON Schema, so teams adopting it should expect to write more of their own tooling glue. For simple, flat configuration with no cross-file validation needs, a plain YAML or TOML file remains the lower-friction choice.
Key Features
- Order-independent unification instead of override-based templating
- Same language expresses schemas, data, and constraints
- Compiles to and validates existing JSON and YAML files
- Command-line tool checks configuration in CI pipelines
- Generates OpenAPI specs and language types from one definition
- Used inside Kubernetes tooling for manifest generation
- Conflicting values produce explicit unification errors
- Declarative only, with no imperative control flow