CUE

CUE — which stands for Configure, Unify, Execute — is a constraint-based configuration language designed to validate, define, and generate structured data at scale. Born from over fifteen years of experience with Google’s internal configuration systems, CUE takes a fundamentally different approach from traditional templating languages by treating types and values as points on a single lattice, where constraints can be combined in any order to produce deterministic results.

History and Origins

CUE was created by Marcel van Lohuizen, a veteran engineer who spent approximately 18-19 years at Google. During his time there, van Lohuizen was a founding team member of Borg — the cluster management system that preceded Kubernetes — and led the development of GCL (Google Configuration Language, also known as BCL or Borg Config Language), which became the dominant configuration language inside Google.

After years of studying system outages and configuration failures at Google scale, van Lohuizen identified two fundamental shortcomings in existing configuration tooling: complexity arising from inheritance-based composition and a lack of meaningful typing. These insights directly shaped CUE’s design.

The first public release, v0.0.2, appeared on GitHub on June 22, 2019. Development moved quickly through approximately fifteen releases by the end of that year. In 2021, the project migrated from cuelang/cue to the cue-lang organization. Van Lohuizen later co-founded CUE Labs with Paul Jolly, headquartered in Zug, Switzerland, which emerged from stealth in October 2025 with backing from Sequoia Capital, OSS Capital, Founders Fund, and Dell Technologies Capital.

Design Philosophy

CUE’s central design principle can be summarized as: “Wrap code in data, not data in code.” Where most configuration languages embed data within a programming language (using loops, conditionals, and inheritance to generate output), CUE starts from the data and layers constraints on top of it.

Three mathematical properties distinguish CUE from its peers:

• Associativity: Grouping of constraint combinations does not affect the result
• Commutativity: The order in which constraints are combined does not matter
• Idempotency: Applying the same constraint twice has no additional effect

These properties mean that configuration from different teams, files, or sources can be merged in any order and always produce the same result. This is a deliberate contrast to inheritance-based systems like GCL and Jsonnet, where the order of application can change the outcome, making large-scale configuration increasingly difficult to reason about.

CUE also follows a push, not pull model for constraints. Rather than requiring explicit template invocation, CUE applies constraints through blanket pattern declarations — if a constraint applies to a structure, it applies everywhere that structure appears, without requiring the author to opt in.

Key Features

Types Are Values

CUE’s most distinctive feature is that types and values exist on a single hierarchy — a partially ordered set (lattice). There is no separate type system: a type is simply a more general value, and a value is simply a more specific type. This collapses concepts like generics, enums, sum types, and null coalescing into unified constructs.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// A type (constraint)
#Person: {
    name: string
    age:  int & >=0 & <=150
}

// A value (more specific point on the lattice)
alice: #Person & {
    name: "Alice"
    age:  30
}

JSON Superset

All valid JSON is valid CUE, enabling incremental adoption. CUE extends JSON with comments, trailing commas, optional quotes on field names, constraints, definitions, and much more.

Multi-Format Interoperability

CUE can import and export between JSON, YAML, Protocol Buffers, OpenAPI, and JSON Schema. This makes it practical as a bridge between different schema and configuration ecosystems.

Constraint-Based Validation

CUE provides fine-grained constraints that double as both validation rules and templates. Constraints can specify exact values, ranges, regular expression patterns, structural requirements, and relationships between fields.

Order-Independent Composition

Because CUE’s merge operation is commutative and associative, constraints from different sources — different teams, different files, different layers of an organization — can be combined without defining an application order. This is essential for managing configuration at scale across large organizations.

Tooling-First Design

CUE was designed from the start to be machine-manipulable. The cue CLI provides commands for evaluation (eval), export (export), formatting (fmt), vetting (vet), and schema definition (def). An LSP implementation shipped with v0.15.0 for editor integration.

Theoretical Foundations

CUE’s lattice-based approach draws from an unexpected source: computational linguistics. The language is rooted in the theory of typed feature structures (TFS) and graph unification, as described in Bob Carpenter’s The Logic of Typed Feature Structures (1992) and Ann Copestake’s Implementing Typed Feature Structure Grammars (2002). These formalisms were originally developed for natural language parsing but provide the mathematical framework CUE uses for constraint propagation and validation.

Comparison with Related Tools

CUE occupies a space alongside several other configuration and data languages, each with different tradeoffs:

CUE and Jsonnet both descend from Google’s GCL but address different shortcomings. Jsonnet focuses on reducing boilerplate through inheritance; CUE focuses on ensuring correctness through constraints. CUE intentionally sacrifices some flexibility for safety and toolability.

Evolution

CUE has evolved steadily since its 2019 debut while remaining pre-v1.0:

• v0.1.0 (April 2020) introduced the streamlined CLI and format interoperability with Protobuf, OpenAPI, and JSON Schema
• v0.2.0 (May 2020) made a significant syntax change, replacing the :: definition notation with #-prefixed identifiers
• v0.3.0 (April 2021) marked the first step toward a backwards compatibility guarantee
• v0.15.0 (2025) shipped initial LSP support and removed the legacy evaluator
• v0.16.0 (March 2025) delivered up to 80% speed improvements on some large projects through type checker caching, with similar gains reported for very large structs

The project has published well over a hundred releases across its history and continues active development under the cue-lang GitHub organization.

Current Relevance

CUE has found its strongest adoption in the Kubernetes and cloud-native ecosystem, where configuration complexity is a persistent challenge. Projects like Istio, KubeVela, and Grafana’s Thema framework use CUE to manage schema evolution and configuration validation.

The formation of CUE Labs in 2025, backed by major venture capital firms, signals growing commercial investment in the language. The company announced a Central Registry for sharing verified CUE modules and a Configuration Control Plane product aimed at enterprise configuration management.

CUE is implemented entirely in Go and distributed as a Go module, with a Go API available for programmatic use. The project is licensed under Apache 2.0 and hosted at github.com/cue-lang/cue.

Why It Matters

CUE represents a principled rethinking of how configuration should work at scale. By grounding its design in lattice theory and computational linguistics rather than conventional programming language constructs, CUE demonstrates that configuration validation and data integrity can be achieved without Turing-completeness or inheritance hierarchies. Its mathematical guarantees — that constraints compose deterministically regardless of order — address a real and costly problem: the configuration errors that cause outages in distributed systems. As cloud-native infrastructure grows more complex, CUE’s approach to taming configuration through constraints rather than code offers a compelling alternative to the status quo.