TL;DR:
- Pkl (pronounced “Pickle”) is Apple’s open-source configuration language — typed, programmable, and designed to generate JSON, YAML, XML, or property files rather than replace them directly
- It solves the copy-paste problem in large configuration estates: define a base template once, extend it per environment, let Pkl’s type system catch misconfiguration at generation time rather than deployment time
- Adoption is still early, but VS Code and IntelliJ extensions exist, and it integrates with Gradle, Swift Package Manager, and can be called from most CI pipelines
YAML has a well-documented problem: it starts simple, and then your project grows. You need the same configuration in slightly different forms across five environments. You start copying and pasting. Some values get parameterised, some don’t. Someone changes a shared value in one place but not the others. A missing field in a staging config doesn’t get caught until it hits production because YAML has no type enforcement and your schema validation was optional. Eventually you have a configuration management problem that’s harder than the application problem it was supposed to solve.
This is the problem Pkl was built for. Apple open-sourced it in February 2024, and by mid-2026 it’s reached a stable 0.26 release with reasonably mature tooling. It’s not a revolution, but for teams with complex configuration requirements it addresses real pain.
What Pkl Actually Is
Pkl is not a replacement for YAML or JSON in the traditional sense. You don’t run Pkl files directly. Instead, Pkl generates configuration output in whatever format your target system expects — JSON for Kubernetes, YAML for CI pipelines, property files for Java applications, XML if you’re unlucky enough to need it.
The workflow is: write configuration in Pkl, evaluate it with the pkl CLI or build tool integration, output the format your target needs. The Pkl source is your source of truth; the generated files are artifacts.
What Pkl adds on top of what YAML/JSON can express:
Types. You can declare that a field must be a String, a Boolean, an integer within a range (Int(1..65535)), or a member of an enumeration. When you evaluate the Pkl file, violations are caught immediately with a clear error message. No waiting for a Kubernetes apply to fail with an inscrutable message about an invalid field value.
Templates and inheritance. Pkl has a class system. You define a base configuration, create environment-specific files that extend it, and override only the values that differ. A Production configuration can extend Base and change three fields. If Base gains a required new field, all inheritors must provide it — the type system enforces this at evaluation time.
Modules and imports. Shared configuration fragments can live in their own files and be imported where needed. Define your standard database connection template once; reference it from every service configuration that needs a database.
Computed values. Fields can reference other fields. If your configuration has a host and a port, a url field can be defined as "\(host):\(port)" and computed automatically. When you change host, url updates.
A Quick Example
// base.pkl
module ServiceConfig
name: String
replicas: Int(1..20)
port: Int(1..65535)
env: "production" | "staging" | "development"
image: String// payment-service.pkl
amends "base.pkl"
name = "payment-service"
replicas = 3
port = 8080
env = "production"
image = "registry.example.com/payment-service:v1.4.2"Run pkl eval payment-service.pkl -f yaml and you get a valid YAML file. Change replicas to 25 and evaluation fails immediately: Int(1..20) expected, got 25. Change env to "prod" and it fails: "production" | "staging" | "development" expected, got "prod".
That’s the pitch: catch configuration mistakes before they leave your laptop.
Integration With Existing Tooling
VS Code: There’s an official Pkl extension with syntax highlighting, type checking, and autocomplete. It’s the most complete editor experience.
IntelliJ/IDEA: Plugin available, somewhat less polished than the VS Code extension as of mid-2026.
Gradle: First-class integration. Pkl templates can generate configuration files as a build step, which is useful for Java/Kotlin services that need generated properties or YAML files baked into their build output.
CI pipelines: pkl eval is a CLI command that exits with a non-zero code on type errors or validation failures. Add it to your CI pipeline before anything tries to use the generated config, and type failures block the build.
Kubernetes: No native Pkl support in kubectl or Helm, but the pattern of using Pkl to generate YAML that you then kubectl apply works cleanly. Compared to Helm templating with its Go template syntax and its particular flavour of YAML escaping issues, Pkl templates are significantly more readable for complex configurations.
When to Reach for Pkl
Your configuration estate has significant duplication. If you have five environment-specific Kubernetes manifests where 90% of the content is identical, Pkl templates cut that to one base file and five small override files.
Configuration mistakes are reaching production too often. If you regularly encounter “wrong value in config” incidents, Pkl’s type system at generation time catches a meaningful class of these before deployment.
You’re starting a new project. The time to adopt Pkl is before you have 200 YAML files, not after.
When to skip it: Small projects, teams with one or two services, or environments where the configuration is already generated by another tool (Terraform, Helm) don’t need another layer. Pkl solves a complexity problem; simple configurations don’t have that problem.
Where Pkl Stands in 2026
Still pre-1.0, still Apple-primary in terms of committer concentration, but meaningfully adopted by teams with complex configuration needs. The language design is stable enough that upgrading minor versions hasn’t been painful for early adopters. The tooling is functional rather than exceptional — the CLI is solid, editor support is adequate.
The competition is real: CUE (from Google) solves a similar problem, Dhall is older and more academically rigorous, and Jsonnet is more widely deployed in Kubernetes-heavy environments. Pkl’s advantage over this field is readability — the syntax is considerably closer to what most developers already write — and the Apple backing means ongoing active development.