Apple’s Pkl: Stop Writing Kubernetes YAML by Hand

YAML does not have a type system. Your Kubernetes manifests don’t know that port should be an integer, not a string. They don’t know that replicas: -1 is invalid. They find out at kubectl apply time — if you’re lucky — or in production, if you’re not. Apple built Pkl to fix this, and two years after open-sourcing it, the language is finally worth your attention.

YAML’s Failure Mode Is a Tax You Pay Daily

Every platform engineer has lived this story: a config change passes CI, passes review, and fails in staging because someone set maxConnections: "10" instead of maxConnections: 10. The YAML parser doesn’t complain. Kubernetes doesn’t complain. Your application crashes and you spend twenty minutes finding a quoted integer.

At small scale, this is annoying. At fifty services across three environments, it’s a full-time job. Helm tries to solve this with Go template syntax — that {{ .Values.foo }} pattern embedded in YAML — which is its own maintenance burden. Kustomize patches on top of existing YAML, which means your bugs travel with your base manifests. Neither tool addresses the root problem: configuration files without types are configuration files without guardrails.

What Pkl Actually Does

Pkl (pronounced “Pickle”) is Apple’s open-source configuration language, released under Apache 2.0 in February 2024. It is intentionally not a general-purpose programming language — Pkl is not Turing-complete, which means configs always terminate and stay predictable. What it adds is exactly what YAML is missing: classes, type annotations, constraints, inheritance, functions, and conditionals. You write Pkl; your tools consume YAML.

The core workflow is one command:

pkl eval my-config.pkl -f yaml

Pkl evaluates your config and outputs valid YAML (or JSON, or XML, or Java properties — your choice). The type checking happens at eval time, before anything touches your cluster. A port value outside the valid range fails loudly:

class DatabaseConfig {
  host: String
  port: Int(this >= 1 && this <= 65535)
  ssl: Boolean = true
}

// This throws at eval time, not at runtime
db = new DatabaseConfig {
  host = "localhost"
  port = 99999  // ERROR: Constraint violated
}

That error fires before kubectl apply ever runs. That’s the shift Pkl delivers.

Pkl for Kubernetes: The Pattern That Scales

Apple publishes an official pkl-k8s package derived from Kubernetes’ own OpenAPI spec. The practical payoff: define your service shape once as a typed class, then instantiate it for every service in your cluster.

class AppConfig {
  name: String
  image: String
  replicas: Int = 1
  port: Int = 8080
  namespace: String = "default"
}

// Two services, no copy-paste
api    = new AppConfig { name = "api";    image = "api:1.2";    replicas = 3 }
worker = new AppConfig { name = "worker"; image = "worker:0.9"; replicas = 2 }

Run pkl eval and you get two valid Kubernetes manifests with correct types enforced. Change the base class — adjust a default label, update a resource limit — and every service inherits the change. This is the pattern YAML forces you to solve with templating workarounds.

For larger setups, the pkg.pkl-lang.org registry includes the AppEnvCluster template, which enforces a three-level directory structure (app / environment / cluster) and merges configs across levels. It’s the kind of opinionated structure that prevents config drift across teams.

Getting Started

Install on macOS:

brew install pkl

Or grab the binary directly from the GitHub releases page — Linux, Windows, and macOS are all supported. VS Code, IntelliJ, and Neovim extensions provide type checking and completion as you write. The official tutorial goes from basic config to Kubernetes manifests in under an hour.

What Pkl Doesn’t Fix

Pkl won’t replace Helm for consuming public charts. Helm’s ecosystem — over 10,000 charts on Artifact Hub — runs on Helm. If you’re deploying Prometheus, Istio, or cert-manager from a public chart, Helm stays in your toolbox. Pkl is for the configs you write and maintain yourself.

The learning curve is real. Pkl has its own syntax — it’s not YAML with extras. The community is active (21,400+ GitHub stars) but you won’t find as many StackOverflow answers as you would for HCL or even CUE. Teams adopting Pkl are early movers, and that carries the usual tradeoffs: better documentation coverage over the next year, more community packages, but also the risk of building on tooling that’s still stabilizing.

The Bottom Line

If your team writes and maintains its own Kubernetes manifests at any real scale, Pkl is worth an afternoon. The type-checking-before-apply workflow closes a gap that YAML has always had and that Helm and Kustomize only paper over. Apple uses it internally. The package ecosystem is growing. v0.31.1 shipped in March 2026.

WWDC 2026 opens June 8. Apple developer tooling is in the spotlight this week. Try pkl eval before someone on your team catches the next quoted-integer incident in production.