yoke: a wasm-based package deployer that replaces Helm templates with programs

A flight is a wasm program that prints Kubernetes resources to stdout

The core idea of yoke is a single sentence in the README: a flight is a wasm executable that outputs the Kubernetes resources making up the package, as JSON or YAML, to stdout. That is the whole contract. There is no chart directory, no values file, no template rendering step. A package is a program, and its output is the resource list the deployer applies to the cluster.

The README argues the case in terms of programming environments: they have control flow, test frameworks, static typing, documentation, error management and versioning, and those are the things you use to build contracts and enforce them. A chart template gives you string substitution; a program gives you typed values and real conditionals.

The output format is deliberately plain. A flight writing JSON or YAML to stdout means the boundary between your code and the cluster is inspectable without running anything. You can capture that output, diff it in review, and see exactly what will be applied. That is a real advantage over a template engine where the final manifest is the result of rendering plus chart defaults plus values merging.

The repository layout backs this up. The `examples/` directory holds `basic/`, `embeddedfs/`, `internal/`, `lookup/`, `redis/` and `unsafelookup/`, which are sample flights rather than chart templates. The `pkg/` and `internal/` directories hold the Go implementation, and `cmd/` holds the command entry points.

wazero embeds a pure-Go wasm runtime, so no sidecar and no custom image

The README states that yoke embeds a pure-Go wasm runtime, wazero, and deploys your flight to Kubernetes. The dependency list confirms it: `github.com/tetratelabs/wazero v1.6.0` appears as a direct requirement in `go.mod`.

Choosing a pure-Go runtime is the detail that makes the design workable. Because the runtime is embedded in the yoke binary, a flight runs inside the deployer process rather than inside a container you have to build, push to a registry and schedule. That is the opposite of the usual Kubernetes packaging model, and it explains the repository's two Dockerfiles: `Dockerfile.yokecd` and `Dockerfile.atc`, the latter presumably for the component the README does not describe.

The `go.mod` file also shows that yoke is not a thin wrapper. Alongside the wasm runtime it depends on `helm.sh/helm/v3 v3.22.0`, the `k8s.io/client-go v0.37.1` client, `k8s.io/apimachinery`, `k8s.io/api` and `k8s.io/apiextensions-apiserver` at v0.37.1, plus `github.com/google/go-containerregistry v0.22.1` for registry access. The module targets `go 1.27.0`.

Two consequences follow. First, yoke inherits Helm's library surface, which is why a Helm-informed project is an easy starting point. Second, the build is not lightweight: the dependency list is long, and it includes terminal interface libraries such as `charmbracelet/bubbletea`, `bubbles` and `lipgloss`, so part of the tool is a rich command line experience rather than a script wrapper.

Installing yoke takes one command from source or one from Homebrew

The README gives two installation routes. From source, the Go toolchain installs the command directly from the module path.

go install github.com/yokecd/yoke/cmd/yoke@latest

That pulls the `cmd/yoke` command from the `github.com/yokecd/yoke` module and places it on your `GOBIN`, so a Go developer needs nothing else. The alternative is the package manager.

brew install yoke

The repository also ships a `Taskfile.yml`, which is the usual way to drive repeatable tasks such as build and release, and a `Dockerfile.yokecd` for running the tool in a container if you prefer that to a local binary.

Once installed, the first thing to do is write a flight and see what it prints. The `examples/basic/` directory is the place to start, and the useful first check is not the apply, it is the output. Because a flight writes its resources to stdout, you can inspect the manifests your program generates before anything touches a cluster.

Official documentation lives at yokecd.github.io/docs, and the README points there for everything beyond installation. That site is where the command reference and the flight authoring guide live, since the README itself covers installation, the concept, versioning and licensing, and stops there.

takeoff, descent, blackbox and mayday map onto apply and rollback

Yoke has an aviation theme, and the core commands are named accordingly: `takeoff`, `descent`, `blackbox` and `mayday`. The README also gives the less whimsical aliases, where `up` and `apply` are the same thing, and `down` and `rollback` are the same thing.

This naming is more than decoration, because the aliases reveal the semantics. `apply` is the operation people already know from `kubectl apply` and from Helm's `upgrade --install`, so the alias lowers the cost of switching. `rollback` is the operation people know from a Helm release. Meanwhile `blackbox` and `mayday` have no alias, which suggests they are diagnostics rather than everyday verbs, though the README does not spell out what they do beyond naming them.

The README adds one capability that maps directly onto a Helm habit. Yoke tracks revisions for each release and supports capabilities like rollbacks and inspection. Revision tracking per release is what makes a rollback meaningful in a package-oriented model, where the deployed artifact is an executable rather than a rendered manifest.

A caveat on the documentation: the README lists the command names but does not document their flags, output format, or how a flight selects a cluster. Those details are in the official documentation rather than in the README, so plan on a short detour to yokecd.github.io/docs before automating yoke in a pipeline.

Pre-1.0.0 versioning means a minor bump can break your deployment

The versioning section is short and blunt. The project is still pre 1.0.0. It uses semantic versioning, but because of that pre-1.0.0 state, breaking changes are represented as minor bumps, and all other changes are patches, until the release of yoke v1.0.0.

That is a specific, testable statement about upgrade cost, and it is unusual enough to plan around. A team that pins yoke at 0.21.x and later moves to 0.22.x may hit a breaking change in what is nominally a minor version bump. The current release line shows how fast that can happen: v0.22.1 was published on 2026-10-10, alongside a `yokecd-installer/v0.21.0` tag on the same day, and a `latest` tag dated 2025-01-23.

The last push to the repository was on 2026-10-16 and the repository is not archived, so work is landing. There is also a `CHANGELOG.md` and a `roadmap.md` at the root, and the README asks issues to be opened on the GitHub repository.

For teams with a strict policy against pre-1.0.0 dependencies, that policy is the deciding factor rather than the quality of the tool. The alternative is to vendor the flights you depend on, since a flight is a program and the README does not describe any stability guarantee for the flight API itself, only for the yoke command's version numbers.

Helm is the comparison that matters, and the difference is static templates versus programs

The README names its predecessor directly: yoke is Helm-inspired, and it exists because Helm relies heavily on static YAML templates. Helm renders a chart, with values, into manifests, and then applies them. Yoke replaces the chart with a compiled program, so the logic that would live in template expressions becomes ordinary code with types, tests and error handling.

That difference shows up in the failure modes. A template that references a missing value usually fails at render time with a message about a key, and a template that loops over a list will happily produce malformed YAML. The same logic in a program is caught by the compiler or by a unit test, and the output is a document you can diff. The cost is that your package now has a build step, a toolchain, and a compiled artifact whose runtime behaviour you inspect by running it rather than by reading a template.

There is also an honest limit to the comparison, because the `go.mod` shows yoke depends on `helm.sh/helm/v3 v3.22.0` directly. The Helm library is part of the yoke build, which means yoke inherits Helm's own release model and its Kubernetes client libraries at v0.37.1. yoke is not a clean-sheet replacement; it is a different authoring surface layered on similar machinery.

On licensing, the README states that yoke is licensed under the MIT License, with a `LICENSE` file at the repository root and a `code-of-conduct.md` alongside a `contributing.md`. The MIT terms are permissive enough for commercial use, and for a package deployer the absence of copyleft obligations means you can adopt it inside a proprietary internal platform without a licensing review slowing you down.

Editorial conclusion

Adopt yoke when your Kubernetes packages need real logic, such as conditionals, loops or computed values, and when your team is comfortable writing and testing that logic in Go or another language that compiles to wasm. Do not adopt it for a simple static chart, where Helm's templating is already enough and yoke adds a build step and a wasm runtime, and do not adopt it if your process forbids pre-1.0.0 dependencies, because the README states that breaking changes are published as minor bumps until v1.0.0. Before you commit, run `yoke takeoff` against a test cluster, confirm the resources the flight emits match what you expected, and check the released version, since v0.22.1 is still well below 1.0.0.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. yokecd/yoke on GitHub