kpt is an Apache-2.0, Go-based, package-centric toolchain that automates the authoring, transformation, validation, and delivery of Kubernetes configuration as data, aimed at platform engineers and infrastructure teams that manage Kubernetes platforms and KRM-driven infrastructure at scale.

What it is

kpt is a command-line toolchain for Kubernetes configuration editing built around the idea of Configuration as Data. In that model, configuration data is the source of truth and is stored separately from live cluster state; configuration is represented with a uniform, serializable data model; the code that acts on configuration is separated from the data and from packages or bundles of that data; and configuration file structure and storage are abstracted away from the operations that act on the data, so clients do not need to interact directly with git or container images. The toolchain ships as several parts: the kpt CLI for package, function, and deployment operations; the kpt API, a separately versioned Go module at github.com/kptdev/kpt/api with type definitions for Kptfile, ResourceGroup, and function result types; the Function SDK at kptdev/krm-functions-sdk; and a function catalog at catalog.kpt.dev.

The concrete problem it addresses is that Kubernetes configuration is normally treated as files to be edited by hand or as something only reachable through imperative commands against a live cluster. kpt replaces that hand-edited, file-centric workflow with a package-centric one: configuration becomes a reusable package, transformations and validation become reusable functions, and the client no longer needs to know whether the underlying storage is git or a container image. The README places kpt in the Kubernetes and KRM ecosystem, naming Config Connector and Crossplane as examples of the KRM-driven infrastructure it is meant to manage.

Key capabilities

• The kpt CLI performs package and function operations and also handles deployment, either through direct apply or through GitOps.
• It keeps an inventory of deployed resources, which enables resource pruning, aggregated status and observability, and an improved preview experience.
• The kpt API module github.com/kptdev/kpt/api exposes schemas including Kptfile, ResourceGroup, and function result types, for building tools that read or write kpt package metadata without depending on the full CLI.
• KRM functions in any general-purpose or domain-specific language transform and validate YAML KRM input and output, are used for in-place transformation, and must therefore be idempotent.
• A Go SDK in the krm-functions-sdk repository simplifies authoring functions.
• The function catalog at catalog.kpt.dev supplies off-the-shelf, tested functions rather than requiring every function to be written locally.
• Configuration as Data abstracts file structure and storage from the operations acting on configuration, so clients do not interact directly with git or container images.

Who uses it and how

• Platform teams managing Kubernetes platforms and KRM-driven infrastructure such as Config Connector and Crossplane at scale, where configuration is packaged and reused rather than edited per cluster.
• GitOps-oriented teams, since the CLI supports delivery via GitOps and the resource inventory drives pruning and aggregated status.
• Tool authors who need to read or write kpt package metadata and therefore depend on the kpt API module instead of the full CLI, which is released independently of it.
• Function authors writing domain-specific transformation, validation, or policy logic in Go through the Function SDK, matching the shift-left validation and policy-as-code topics.
• Teams that consume existing tested functions from catalog.kpt.dev rather than authoring their own.

Getting started

Installation instructions for the kpt CLI are published at kpt.dev/installation/kpt-cli, and the kpt website at kpt.dev is the starting point for specific features, the FAQ, and the rationale guide.

How it compares

The topic list places kpt alongside kubectl and kustomize, so it sits in the same Kubernetes configuration tooling space as imperative apply and file-level customization. It differs in being package-centric and in separating the code that acts on configuration from the data and from bundles of that data, with a resource inventory driving pruning and aggregated status. No paid products are named as replaced.

When to use it — and when not to

The self-hoster operates a CLI and its surrounding packaging and delivery workflow, with no database or mail service implied by the README. Teams that do not work in KRM-shaped configuration, or that cannot guarantee idempotent in-place transformations, should look elsewhere. Honest weaknesses: the README is thin and defers most detail to the external site, the CLI and API module are versioned and released independently so release surfaces must be tracked in release/README.md, and the repository carries 324 open issues against 1,894 stars.