Kapitan is an open source, inventory-driven configuration management tool that compiles reusable YAML classes and targets into rendered Kubernetes manifests, Terraform resources, and other infrastructure artifacts for platform engineering and GitOps teams.

What it is

Kapitan is a Python tool, listed in this registry under Infrastructure & Operations / Orchestration & Scheduling, that lives in the Kubernetes and Terraform infrastructure ecosystem. It models configuration as a hierarchical inventory of reusable classes and per-environment targets written in YAML, then compiles that inventory through a set of input templates into a tree of generated files under compiled/. Templates can be written in Jsonnet, Jinja2, or Kadet (Python), and the tool also accepts Helm, Kustomize, and CUE inputs. Secrets, remote dependencies, and validation are handled by the same compile step rather than by separate tooling.

The concrete problem it solves is value duplication. In a typical stack, the same endpoint, image tag, or replica count is copied across Helm values files, Kustomize overlays, and Terraform variables, and each copy drifts independently. Kapitan replaces that duplication with a single inventory definition, letting each input type generate the files it needs from the same source data. Teams define values once and let Jsonnet, Jinja2, Helm, or Kustomize render them per target.

Key capabilities

• Single compile entrypoint: kapitan compile turns an inventory plus input templates into the compiled/ output tree.
• Multiple input types: Jsonnet, Jinja2, Kadet (Python), Helm, Kustomize, CUE, external commands, and copy/remove operations.
• Native secret management integrated with GPG, HashiCorp Vault, AWS KMS, GCP KMS, and Azure Key Vault.
• Remote dependencies fetched over Git, HTTP, and ORAS (OCI registry).
• Validation of generated output using JSON Schema, TOML, and YAML linting.
• GitOps-friendly output: compilation produces fully rendered, plain-text files suitable for committing.
• Inventory-driven reuse through YAML classes and per-environment targets.

Who uses it and how

• Platform engineering teams that manage Kubernetes and Terraform from one configuration source instead of maintaining separate variable sets.
• GitOps teams that commit the rendered compiled/ output and let a delivery controller apply it, since output is plain text with no runtime templating.
• Multi-environment organisations that map each environment to a target in the inventory and reuse classes across them.
• Teams already invested in Helm, Kustomize, Jsonnet, or CUE that want an inventory layer above those tools rather than a replacement for them.
• Users who need the community channel #kapitan on Kubernetes Slack or the kapitan-reference repository as a working starting point.

Getting started

The README recommends Docker with docker run -t --rm -v $(pwd):/src:delegated kapicorp/kapitan -h, adding -u $(id -u) on Linux to preserve file permissions. Alternatively, install with pip3 install --user --upgrade kapitan on Python 3.10 or newer, or scaffold a project with cruft create https://github.com/kapicorp/kapitan-reference --checkout cookiecutter --no-input.

How it compares

No list of paid products is given in the facts, so the relevant comparison is with the tools Kapitan consumes rather than replaces. Helm, Kustomize, CUE, Jsonnet, and Jinja2 all appear as supported input types, which places Kapitan above them as an inventory and compilation layer rather than as a competing renderer. A team that only needs to render one Helm chart gains nothing from the extra layer.

When to use it — and when not to

A self-hoster must operate the secret backends the workflow depends on, whether that means GPG keys, HashiCorp Vault, or cloud KMS access, and must keep either Python 3.10 or newer or the kapicorp/kapitan Docker image available. The repository carries 155 open issues, and the licence metadata is inconsistent: the README badge points to MIT while this registry entry lists Apache-2.0, so anyone adopting it for compliance-sensitive work should confirm the licence in the repository itself. Teams that only template a single chart or a handful of Terraform files should not add an inventory layer they will not reuse.

git clone https://github.com/kapicorp/kapitan-reference.git kapitan-templates
cd kapitan-templates
./kapitan compile

pip3 install cruft
cruft create https://github.com/kapicorp/kapitan-reference --checkout cookiecutter --no-input

docker run -t --rm -v $(pwd):/src:delegated kapicorp/kapitan -h

pip3 install --user --upgrade kapitan