Pkl

Pkl — pronounced “Pickle” — is an open-source, configuration-as-code language created at Apple and released to the public in early 2024. It sits deliberately in the middle ground between a static data format like JSON or YAML and a full general-purpose programming language: simple configuration looks much like writing key/value data, but when complexity demands it, Pkl offers classes, functions, conditionals, loops, type annotations, and constraints. The result is configuration that can validate itself before anything is deployed, scale from a handful of settings to large hierarchies of shared modules, and be rendered out to whatever format a system actually consumes.

History & Origins

For decades, the default way to configure software has been a static text format — most commonly JSON or YAML, sometimes XML or .properties files. These formats are easy to read and universally supported, but they share two persistent weaknesses: they cannot express logic, so configuration is endlessly copied and pasted with small variations; and they cannot validate themselves, so a typo, a wrong type, or an out-of-range value is often only discovered when a system fails at runtime.

The common workarounds each carry their own cost. One option is to bolt external validation (such as JSON Schema) onto a static format. Another is to generate configuration from a general-purpose language — a Kotlin or Python DSL, say — which solves expressivity but ties the configuration to that language’s ecosystem and pulls in a heavyweight runtime just to produce some YAML.

Pkl was Apple’s answer to this dilemma. The team behind it had used the language internally for a number of years to manage configuration before deciding to release it as open source. In early February 2024, Apple published Pkl at version 0.25.0 under the Apache-2.0 license, complete with a command-line tool, documentation at pkl-lang.org, IDE plugins, and an announcement post titled “Introducing Pkl, a programming language for configuration.” The premise was that configuration deserves its own dedicated language — “a blend between a static configuration format and a general-purpose programming language” — rather than being forced into one extreme or the other.

Design Philosophy

Pkl’s design is organized around a small set of goals:

• Catch errors before deployment. Configuration should be validated as it is written, not when a service crashes. Pkl’s type system and constraints make many classes of mistake impossible to express.
• Scale with complexity. A trivial config file should stay trivial, but the same language should gracefully absorb abstraction, reuse, and parameterization as needs grow — without switching tools.
• Be a pleasure to write. First-class IDE support — autocompletion, navigation, inline error reporting — was a priority from the start, delivered through editor plugins and a language server.
• Stay ecosystem-neutral. Because Pkl is its own language rather than a DSL embedded in Kotlin or Python, configuration written in Pkl is not bound to any host language’s runtime. It can be rendered to a static file or embedded as a library in many environments.

Crucially, Pkl is a specialized, declarative language. It is not meant to be a general-purpose programming language; its features exist to describe and validate configuration, and the language intentionally avoids the open-ended capabilities (and risks) of a general-purpose runtime.

Key Features

• Types and constraints. Properties can carry type annotations, and those types can include arbitrary constraints — for example, a port that must be an integer between 1 and 65535, or a string that must match a pattern. Violations are reported as the configuration is evaluated.
• Amending (inheritance for config). Pkl’s signature mechanism lets one object amend another, overriding and extending values while inheriting defaults. This replaces large amounts of duplicated YAML with a clean hierarchy of base modules and overrides.
• Functions, conditionals, and generators. Real language constructs — functions, if/else, for generators, and more — make it possible to compute values and produce repeated structures programmatically instead of by hand.
• Multiple output formats. A single Pkl module can be rendered to JSON, YAML, XML property lists, .properties, and other formats, so existing systems consume Pkl’s output without knowing Pkl exists.
• Code generation for host languages. Pkl can generate typed classes/structs for Swift, Go, Java, and Kotlin, so application code reads configuration as native, type-safe objects rather than parsing raw text.
• Packages and tooling. Modules can be published and depended upon through a package manager, and the language ships with CLI tooling, editor plugins (IntelliJ/JetBrains, VS Code), a language server, and build integrations such as a Gradle plugin and Spring Boot support.

A flavour of the syntax

// A small server configuration with types and a constraint
class Server {
  host: String = "localhost"
  port: Int(this in 1..65535) = 8080
}

server: Server = new {
  host = "example.com"
  port = 443
}

// Amend the base to make a staging variant that reuses defaults
staging: Server = (server) {
  host = "staging.example.com"
}

Here port is constrained to a valid range, server is constructed with new, and staging is produced by amending server — inheriting its values and overriding only the host. Evaluating this module can emit equivalent JSON or YAML for downstream tools.

Evolution

Pkl is a young language, and its public history begins with the 0.25.0 open-source release in early 2024. Development since then has been steady and incremental: the project moved through the 0.28, 0.29, and 0.30 release lines during 2025, and reached 0.31.0 in February 2026 with the 0.31.1 maintenance release following in March 2026.

As of mid-2026 Pkl remains pre-1.0, which signals that its maintainers reserve the right to evolve the language, but it is far from experimental: it ships production tooling, has a documented standard library, and releases on a regular cadence.

Current Relevance

Pkl arrived into an active conversation about how to tame configuration sprawl, alongside peers such as Jsonnet, Dhall, CUE, and HCL. Its distinguishing pitch is the combination of a rich type-and-constraint system, a clean amending model for reuse, multi-format output, and first-class code generation into mainstream languages — all backed by Apple’s stewardship and genuine IDE support.

Typical adopters are teams drowning in repetitive, error-prone YAML: Kubernetes and cloud-native platform engineers generating manifests, application teams that want their config to arrive as typed objects in Swift, Go, Java, or Kotlin, and infrastructure teams consolidating shared defaults into reusable modules. Because Pkl can be embedded as a library or run as a CLI, it slots into existing pipelines without forcing a wholesale migration.

Why It Matters

Pkl is a notable entry in a long line of attempts to answer a deceptively simple question: what is the right language for configuration? Static formats are too weak; general-purpose languages are too much. By treating configuration as a first-class problem deserving its own declarative, strongly typed, validation-oriented language — and by backing it with the tooling, code generation, and corporate weight of Apple — Pkl makes a serious case that the “Goldilocks” middle ground is not only possible but practical. Whether or not it becomes ubiquitous, it crystallizes a clear philosophy: configuration should be safe by construction, reusable by design, and pleasant to write.