# Grafana Tanka: Jsonnet for Kubernetes, and When It Beats YAML

> Tanka renders Kubernetes manifests from Jsonnet with a diff step before apply. It suits platform teams that want reusable configuration; it is the wrong tool for anyone who only edits plain YAML.

**grafana/tanka** — Flexible, reusable and concise configuration for Kubernetes

- Repository: https://github.com/grafana/tanka
- Website: https://tanka.dev
- Stars: 2,688 · Forks: 193
- Language: Go
- License: Apache-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/grafana-tanka

## What Grafana Tanka solves, and for whom

Kubernetes configuration is repetitive. The same Deployment skeleton, the same labels, the same resource limits appear across environments with small differences. YAML has no way to express that reuse, so teams copy files and drift. Tanka's answer is to write configuration in Jsonnet, a language with functions, imports and object merging, and to render it into Kubernetes manifests on demand. The README describes it as "the clean, concise and super flexible alternative to YAML for your Kubernetes cluster" and lists reusability as a core property: build libraries, import them, share them on GitHub.

The intended user is a platform or infrastructure engineer who manages more than a handful of manifests and is comfortable with a programming language. The repository ships a Grafana Labs library set (grafana/jsonnet-libs, linked from the README) as the kind of reusable code Tanka is designed to consume. If your configuration is ten static files that rarely change, the Jsonnet learning cost buys you very little.

## How tk renders Jsonnet into cluster objects

The CLI is `tk`, built from ./cmd/tk in the repository. A Tanka project is a directory of Jsonnet files plus a metadata file that tells the tool which cluster and namespace the environment targets, and where the Jsonnet entry point lives. Running a command evaluates the Jsonnet, producing plain Kubernetes objects, then either prints them, diffs them against the live cluster, or applies them.

The README highlights `tk diff` as the confidence mechanism: "Stop guessing and use `tk diff` to see what exactly will happen". That ordering matters. Tanka does not apply a template and hope; it computes the object set first, so the diff is between rendered output and cluster state. Jsonnet evaluation itself is handled by the google/go-jsonnet library, and the go.mod pins k8s.io/apimachinery v0.37.0, which is what the rendered objects are shaped against. Helm charts are handled by vendoring them in, modifying them, and exporting them, which the README calls reproducible. In practice that means the chart source lives in your repository rather than being fetched at apply time.

## Installing tk and running a first diff

The README points to https://tanka.dev/install for installation and to https://tanka.dev/tutorial/overview for the tutorial. The repository's Makefile builds the binary from source with Go, which is the path to take if you want a specific revision.

The install target compiles the CLI with CGO disabled and stamps a version into it, placing the binary in your Go bin directory:

```bash
make install
```

The Makefile also defines a static build, which produces a binary with no CGO dependency and the same version stamp:

```bash
make static
```

After that, `tk` is on your PATH. The repository also carries a Dockerfile that stages kubectl, jsonnet-bundler, Helm and kustomize into the image, so a container build gives you the tooling Tanka shells out to. The Dockerfile pins kubectl 1.34.11, Helm 3.21.1 and kustomize 5.8.1 as build arguments, which is a useful reference for the versions the project expects to work with.

From there the documented path is the tutorial site. The README does not inline a full project walkthrough, so the first real use is: create a project per the tutorial, point it at a cluster, write Jsonnet that emits a Deployment, and run the diff before anything is applied.

## Where Tanka gets in your way

Jsonnet is the whole cost. It is a real language with its own semantics for object merging, late binding and imports, and the README's own framing assumes you will read jsonnet.org to learn it. A team that cannot read Jsonnet cannot review a Tanka change, because the manifest a reviewer wants to see is the output, not the source. That is a genuine organisational constraint, not a tooling detail.

The second constraint is the dependency surface. Tanka is a Go binary that shells out to kubectl, Helm and kustomize for parts of its work, and the Dockerfile exists precisely because those tools need to be present at known versions. If you install the binary alone and your environment has a mismatched Helm or kustomize, the failure will surface at render time rather than at install time.

Third, the README is thin on operational detail. It documents installation and community channels, and it links to the tutorial and the Jsonnet docs, but the README itself does not document rollback behaviour or what happens when a diff is applied against a cluster that has drifted. Those answers live in the docs/ directory and the tutorial site, not in the repository front page, and a reader should treat the README as an entry point rather than a complete manual.

## Tanka against Helm and Kustomize

Helm templates YAML with Go templates and ships charts as versioned packages. The difference is where the logic lives: Helm puts conditionals and loops inside the YAML file, so the template and the manifest share a document. Tanka keeps the manifest as the output and the logic in a separate Jsonnet program, which is why `tk diff` can show you a rendered result rather than a template expansion. Tanka also consumes Helm charts, but by vendoring and exporting them, so the chart becomes source in your repository instead of a remote dependency resolved at deploy time.

Kustomize takes the opposite approach again: no language, just overlays and patches applied to base YAML. That is far easier to learn and is built into kubectl. It also cannot express computed values, loops over a list of services, or shared functions, which is exactly the gap Jsonnet fills. If your variation between environments is a handful of field overrides, Kustomize is the smaller tool and the better fit. If your variation is structural and repeated, Tanka's model pays off.

## Maintenance, releases and licence

The repository is not archived and the last push was on 2026-09-24. Releases are frequent and follow semantic versioning: v0.39.0 on 2026-08-27, v0.39.1 on 2026-09-14 and v0.39.2 on 2026-09-21. The CHANGELOG.md and release-please configuration files at the repository root indicate releases are generated from commit history, so upgrade notes are available in the changelog rather than only in release announcements.

Upgrade cost is mostly the Go toolchain. go.mod declares go 1.26.1 with toolchain go1.27.1, so building from source requires a recent Go. The Kubernetes dependency is pinned to k8s.io/apimachinery v0.37.0, which means the object shapes Tanka renders track that version; a cluster far ahead of or behind it is worth checking against before you upgrade tk. The Makefile provides `make install` and `make static` for a static binary, and `make cross` for linux, darwin and windows builds.

Tanka is licensed under Apache-2.0, with the LICENSE file at the repository root and a GOVERNANCE.md alongside it. Apache-2.0 permits commercial use and modification and includes a patent grant; it also requires that you preserve notices and state changes. This is a description of the licence text, not legal advice. If you redistribute a modified tk, read the LICENSE file itself.

## Conclusion

Adopt Tanka if you already run Jsonnet or want reusable, parameterised Kubernetes configuration and are willing to learn the language. Do not adopt it if your manifests are small, edited by hand, and understood by people who will not learn Jsonnet. Before committing, verify that the Kubernetes version your cluster runs is compatible with the k8s.io/apimachinery v0.37.0 dependency pinned in go.mod, and read the docs/ directory to confirm which flags your installed tk version actually accepts.

## FAQ

### How do you install Grafana Tanka?

The README points to https://tanka.dev/install for installation instructions. The repository also builds from source with Go: the Makefile's install target compiles ./cmd/tk with CGO disabled and stamps a version into the binary.

### What is Grafana Tanka?

It is a tool for writing Kubernetes configuration in Jsonnet instead of YAML, then rendering, diffing and applying it to a cluster. The README describes it as the clean, concise and flexible alternative to YAML for Kubernetes.

### Does Grafana Tanka work with Helm charts?

Yes. The README lists Helm support and describes vendoring charts in, modifying them, and exporting them reproducibly. The Dockerfile installs a pinned Helm version, 3.21.1, as a build argument.

### What command shows what Tanka will change before applying?

The README names `tk diff` as the way to see exactly what will happen, describing it under the heading of confidence. The rendered Jsonnet output is compared against the live cluster before you apply.

### What licence is Grafana Tanka released under?

Apache-2.0. The LICENSE file is at the repository root, and GOVERNANCE.md sits beside it. The README states the project is free as in beer and as in speech.

## Sources

- [grafana/tanka on GitHub](https://github.com/grafana/tanka)
- [License: Apache-2.0](https://github.com/grafana/tanka/blob/main/LICENSE)
- [Project website](https://tanka.dev)
- [README](https://github.com/grafana/tanka/blob/main/README.md)
- [Releases](https://github.com/grafana/tanka/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/grafana-tanka