Preview every change and deploy in dependency order.
Compare your compiled cluster definition against live Kubernetes state, post package-grouped plans on pull requests, and record a deployment receipt on the cluster.
End-to-end delivery lifecycle
- 01pull request edit cluster or package Nix files
- 02kix check validate wiring, quotas, and policy offline
- 03kix diff / plan preview package-grouped changes on the PR
- 04merge every release is a Git commit
- 05kix deploy apply in dependency waves and wait on readiness
- 06receipt record commit and image digests on the cluster
Terminal output ($ kix diff shop)
$ kix diff shop12 packages: 9 unchanged, 2 changed, 1 added, 0 removed monitoring ~ grafana 11.2.0 (1 changed, 1 dep-affected) ~ Deployment/grafana@monitoring ~ $.spec.replicas: old: 1 new: 2 ~ PackageInstance/grafana@monitoring (via dependency) shop + valkey 8.0.2 (4 resources) ~ web 1.4.2 -> 1.5.0 (1 changed, 2 dep-affected) ~ Deployment/web@shop ~ $.spec.template.spec.containers[web].image: old: "ghcr.io/acme/web:1.4.2" new: "ghcr.io/acme/web:1.5.0" ~ HorizontalPodAutoscaler/web@shop (via dependency) ~ PackageInstance/web@shop (via dependency) Activation: shop-ll6g0k5f2kqm -> shop-6w9czkc51502Preview package-grouped diffs locally and on pull requests
Before deploying, kix diff compares the compiled cluster against live Kubernetes state and groups every change by namespace and package, separating direct field edits from downstream via dependency hash updates.
In CI, kix diff -o markdown posts the summary directly to the pull request so reviewers inspect the exact package and resource impact alongside the code change.
Pull request comment ($ kix diff shop -o markdown)
kix diff
Plan: 2 updated, 1 added, 0 removed, 9 unchanged Resources: 2 with real content changes, 3 dep-affected (hash bump only)
Added packages
-
shop/valkey8.0.2 (4 resources)
Changed packages
-
monitoring/grafana11.2.0 (1 changed, 1 dep-affected) -
shop/web1.4.2 → 1.5.0 (1 changed, 2 dep-affected)
Activation: shop-ll6g0k5f2kqm to shop-6w9czkc51502
Roll out in dependency waves from CI or your laptop.
Because the cluster definition and image pins live in Git, you can run kix deploy from your laptop or any CI pipeline. Kix schedules resources wave by wave along the dependency graph and waits for each wave to report ready before applying the next.
An optional in-cluster operator is in development.
$ kix deploy shop scheduled along the dependency DAG
- wave 1 Secret/dbConfigMap/web
- wave 2 Cluster/dbDeployment/valkey
- wave 3 Service/webDeployment/web
- wave 4 HTTPRoute/web
- kix plan
- Runs the deploy pipeline as a server-side dry run (dryRun=All) to surface webhook rejections, field ownership conflicts, and migrations before applying.
- kix drift
- Reports Kix-managed resources whose applied fields changed on the live cluster since the last deploy, and which field manager changed them.
- --prune
- Removes resources no longer defined in your cluster, except Namespaces and CRDs. Without --prune, the plan lists orphans and leaves them in place.
- kix snapshot
- Saves the Kix-managed resources of a live cluster to disk, so kix diff --from can compare against a point-in-time snapshot later.
Deployment receipts & audit evidence
Kix records a receipt for each deployment on the cluster, so you can trace what is running back to the inputs and images that produced it.
- during an incident
“What changed since yesterday?”
Each receipt records the commit, whether the working tree was clean, the tool versions, and the container images.
- during a release
“Did the new build actually go out?”
Image versions and digests live in a committed file, which lets you trace a release to a commit. kix pin check --source-rev fails when a pinned image was built from a different commit.
- during a rollback
“Put back exactly what ran on Tuesday.”
kix rollback reapplies a previous deploy's activation from the local build cache, and kix gc retains at least the 10 newest records.
- during an audit
“Show me evidence.”
kix compliance produces a CycloneDX SBOM, an unsigned SLSA provenance statement, and an audit bundle mapped to SOC 2, ISO 27001, DORA, or NIS2. An auditor can use these artifacts as evidence when assessing compliance.
- cluster
- shop
- activation
- shop-6w9czkc51502
- deployed
- 2026-09-09 10:47
- commit
- 700ab95
- working tree
- clean
- kix
- 0.1.0
IMAGES
ghcr.io/acme/web:1.5.0 @sha256:4a8e91c0…
ghcr.io/valkey-io/valkey:8.0.2 @sha256:7377697a…