# kpack runs Cloud Native Buildpacks as a Kubernetes controller

> kpack extends Kubernetes with custom resources so that container images are built by a controller inside the cluster rather than by a CI job on a laptop. You declare a builder and an image, and the image is rebuilt when the source, the buildpack or the stack changes, with the buildpacks platform doing the actual work.

**buildpacks-community/kpack** — Kubernetes Native Container Build Service

- Repository: https://github.com/buildpacks-community/kpack
- Stars: 1,089 · Forks: 177
- Language: Go
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/buildpacks-community-kpack

## A build service expressed as Kubernetes custom resources

The gap kpack fills is between two worlds that usually do not meet well. Cloud Native Buildpacks give you a repeatable way to turn source code into an OCI image, with the build steps and the runtime chosen by a builder configuration. Kubernetes gives you a declarative API where you describe desired state and a controller reconciles it. The buildpacks model is imperative and runs on a workstation or a CI worker. The Kubernetes model is declarative and runs in the cluster.

kpack joins them. The README describes it as a Kubernetes native container build service that extends Kubernetes and uses unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks. The word unprivileged is doing real work in that sentence, since the whole approach is built on running builds with ordinary cluster permissions rather than with a privileged builder pod.

The audience is platform engineers. Anyone can run a buildpack build locally; kpack is for the team that wants every application in the organisation to be built the same way, from a builder that is version controlled, without each team maintaining a CI pipeline for the build step. The topics on the repository are buildpacks, cloud-native, kubernetes and hacktoberfest, which places it firmly in the platform layer rather than in developer tooling.

## Three resources: builders, images and one-off builds

The README names the API surface in three sentences, and each sentence is a distinct kind of thing you can declare.

The first is the builder resource, which configures a Cloud Native Buildpacks build configuration with the desired buildpack order and operating system stack. A builder is therefore a policy object: it says which buildpacks run, in what order, and on which operating system stack. It is the piece your platform team owns, and it is the piece you would want in version control.

The second is the image resource, which builds an OCI image and schedules rebuilds on source changes and from builder buildpack and builder stack updates. This is the resource an application team writes, and it points at a builder plus a source, and the controller keeps the image in step with both.

The third is a build type to execute a single Cloud Native Buildpack OCI image build, which is the escape hatch for a one-off build rather than a continuously maintained image.

The distinction between the first and the second is the whole design. Because a builder is separate from an image, upgrading a buildpack or moving to a new stack becomes a change to one shared object rather than a rebuild of every application, and the image resources pick the change up because the controller watches for builder updates.

## Rebuilds are triggered by the controller, not by a webhook you wire up

The rebuild behaviour is the part that differs most from a conventional CI setup, and it deserves to be understood before you adopt the project.

An image resource schedules rebuilds on source changes and from builder buildpack and builder stack updates. So the triggers are: the source moved, the buildpack set in the builder changed, or the stack underneath changed. There is no separate pipeline definition to keep in step, because the builder is the pipeline.

This also has a consequence for the layers above. If your source lives in a git repository, kpack needs a way to read it and to know when it moved, and the module dependencies show that it uses go-git for that, along with the git-urls library for parsing repository locations. The buildpacks lifecycle library, version 0.20.12 in the module file, is what actually performs the build steps, and the imgutil library handles image manipulation. The image is pushed through go-containerregistry, with an Azure storage SDK dependency in the list for blob storage.

The result is a closed loop inside the cluster. Source change, controller notices, build runs in the cluster, image is updated, and the workload can be pointed at it. The flip side is that the cluster becomes the place where builds happen, with the resource usage, the network egress requirements and the failure modes that implies.

## The sample manifests show the feature set kpack expects you to use

The samples/ directory is the closest thing to a quick reference for the API, and the file names are informative because they map to specific capabilities rather than to example applications.

There is a builder.yaml and a cluster_builder.yaml, so both a namespaced builder and a cluster scoped builder are part of the design. A cluster_stack.yaml and a cluster_store.yaml indicate the same split for the stack and for the buildpack store, which matches the idea that platform level pieces are cluster scoped while application level pieces are not.

The image samples are where the options become visible. There is image_from_git.yaml and image_from_blob_url.yaml, so a build can take its source from a repository or from a blob URL. There is image_with_cache.yaml, which implies build caching is a first class field on the resource rather than a global setting. And there are two service binding samples, image_with_service_bindings.yaml and image_with_legacy_cnb_service_bindings.yaml, with the older form kept in a directory of its own, docs/legacy-cnb-servicebindings.md, which tells you the service binding behaviour changed at some point and that both shapes are still documented.

There is also a build.yaml, matching the build type the README mentions for a single build. Note what is not here: no sample of a multi-stage pipeline, no sample of a build matrix, no sample of a deployment step. kpack stops at producing the image.

## The dependency list reveals the supply chain features underneath

The module file is long, but a few entries tell you what kpack does that a plain build script would not.

The signature and attestation entries are the notable ones. The module requires sigstore/cosign at version 2.5.3 and sigstore/sigstore at 1.9.5, along with the notary client from the update framework, and in-toto-golang for in-toto attestations. The go-securesystemslib dependency is the library that implements the securesystemslib signing format used by in-toto and sigstore tooling. Put together with the Azure storage SDK and go-containerregistry, this says that signing images and producing attestations is part of what the project is built to do, not an add-on.

The Kubernetes versions matter too. The module requires k8s.io/api and k8s.io/apimachinery at 0.34.3 and uses k8s.io/client-go, so a kpack release is tied to a particular Kubernetes API generation. The go directive is 1.24.5, and the module path is still github.com/pivotal/kpack even though the repository now lives under the buildpacks-community organisation, which is a naming artefact worth knowing if you write replace directives or vendoring rules.

The Makefile shows how the project is tested, and the shape is conventional:

```bash
unit:
	$(GOCMD) test ./pkg/...
```

with a separate end to end target that runs against the test directory with a thirty minute timeout:

```bash
e2e:
	$(GOCMD) test --timeout=30m -v ./test/...
```

Unit tests live under pkg/, and the end to end suite lives under test/, so the split between fast checks and cluster level checks is visible from the layout.

## kpack against pack: the build moves from your machine into the cluster

The README anticipates the obvious comparison and points readers who already know pack to a dedicated document, docs/kpack-vs-pack.md, alongside the tutorial and the concept guides for stacks, images, secrets, buildpacks and stores, builders, builds and service bindings.

The architectural difference is the important one, and it follows from how each tool is deployed. The pack CLI is a command you run, which produces an image and pushes it, with the build happening wherever you ran the command. kpack is a controller in the cluster, where the image resource is the desired state and the build is an outcome that the cluster reconciles toward. The README makes the resulting behaviour explicit: rebuilds are scheduled on source changes and on builder updates, without a pipeline in between.

That difference is the reason to choose kpack over a local build, and it is also the source of its costs. The pack route has no cluster to operate and no builder object to curate. The kpack route gives you one place where builders, stacks and stores are declared once and applied everywhere, and in exchange asks you to run a controller, to think about cluster scoped resources, and to accept that the build now consumes cluster capacity and depends on cluster egress.

The interaction story is similar for both. kpack has its own CLI, documented in a separate kpack-cli repository, and the README mentions a log utility for tailing build logs, with its own page in the docs directory. Whether you use pack or kpack, the end product is the same kind of OCI image built by the same Cloud Native Buildpacks platform

## Apache-2.0 and a project with visible governance paperwork

The licence is Apache-2.0, with a LICENSE file and a NOTICE file at the repository root. For a component that runs inside a cluster and produces the images your workloads run, the Apache licence terms, including the patent grant, are a common and practical choice for platform components, and the NOTICE file matters if you redistribute builds derived from it.

The repository carries an unusually complete set of process files, and they tell you how the project is run. There is GOVERNANCE.md and MAINTAINERS.md for how decisions are made and who maintains what, CODEOWNERS for who reviews which paths, CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md for how to report a vulnerability, SUPPORT.md for where to get help, and VERSIONING.md plus RELEASE.md for how versions are cut. ADOPTERS.md records who is using the project, and a PacmanFile is present alongside a Tiltfile, the latter being the local development loop that DEVELOPMENT.md describes.

The release record is steady. The recent tags are v0.18.0 on 2026-07-15, v0.17.2 on 2026-06-18 and v0.17.1 on 2025-12-09, and the last push was on 2026-08-17. The project is still at version 0.x, which in practice means the API and behaviour can still change between minor versions, and the VERSIONING.md file is the place to check what a given bump means. The project also runs a weekly working group meeting and has a channel in the CNCF Slack workspace, so there is a place to ask questions that is not only the issue tracker.

## Conclusion

Adopt kpack if your organisation already runs Kubernetes and wants image builds to happen in the cluster with the same declarative model as the workloads they deploy, and if you are prepared to maintain a builder and a stack as platform configuration. Do not adopt it for a single developer building an image from a laptop, because the kpack CLI plus a local build is the smaller setup, and do not adopt it if your platform team does not want to own buildpacks and stacks as infrastructure. Before you start, read the install guide and the tutorial in the docs directory, decide whether your cluster will run a cluster builder, a cluster stack and a cluster store as the sample file names suggest, and check the version you plan to deploy against the v0.18.0 release and the Kubernetes API versions the module depends on.

## FAQ

### What is kpack and what problem does it solve?

kpack is a Kubernetes native container build service. It extends Kubernetes with custom resources and uses unprivileged Kubernetes primitives to build OCI images with Cloud Native Buildpacks, so image builds run in the cluster as part of the platform rather than in a separate CI pipeline.

### What are the kpack builder, image and build resources?

A builder configures a Cloud Native Buildpacks build configuration with the desired buildpack order and operating system stack. An image builds an OCI image and schedules rebuilds on source changes and on builder buildpack or stack updates. A build executes a single Cloud Native Buildpack OCI image build.

### How do I get started with kpack?

The README points to an install guide in docs/install.md and a tutorial in docs/tutorial.md, with separate concept pages for stacks, images, secrets, buildpacks and stores, builders, builds and service bindings. Interaction is done with the kpack CLI, and build logs can be tailed with the kpack log utility.

### How is kpack different from pack?

pack is a command line client that performs a build where you run it, while kpack is a controller in the cluster that reconciles an image resource and schedules rebuilds on source changes and on builder updates. The README points readers familiar with pack to the comparison page at docs/kpack-vs-pack.md.

### Does kpack support image signing and attestations?

The module dependencies include sigstore/cosign, sigstore/sigstore, the notary client and in-toto-golang, together with go-securesystemslib, so signing and attestation tooling is part of the dependency set. The specific configuration options for them are not described in the README.

## Sources

- [buildpacks-community/kpack on GitHub](https://github.com/buildpacks-community/kpack)
- [Issues](https://github.com/buildpacks-community/kpack/issues)
- [License: Apache-2.0](https://github.com/buildpacks-community/kpack/blob/main/LICENSE)
- [README](https://github.com/buildpacks-community/kpack/blob/main/README.md)
- [Releases](https://github.com/buildpacks-community/kpack/releases)

---

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