Pre-commit feedback
Broken dependencies and policy violations are caught before you commit.
It turns your cluster definition into a verifiable cluster artifact, so teams can understand, change, and operate Kubernetes with confidence.
Feedback moves earlier, deployments become inspectable, and operations are driven by the same evaluated cluster model.
Broken dependencies and policy violations are caught before you commit.
Preview the evaluated result, then apply it in dependency order.
Diff, graph, evidence, drift, deploy order, rollback.
A developer renames the Postgres instance from
postgres to
pg and misses one reference. The
cluster would compile, deploy, and only fail when the app first
tries to read the database. Kix fails the build at commit time,
with the fix in the error.
cluster.nix
{
kix.instances = {
pg = {
package = pkgs.cloudnative-pg-cluster;
namespace = "data";
};
api = {
package = acmePackages.api;
namespace = "acme-prod";
deps.database = ref "postgres";
};
};
}
$ kix check prod-eu
error: api.deps.database
references unknown instance "postgres"
did you mean "pg"?
prod-eu: 1 error
build aborted, nothing deployed
You can also diff against the deployed cluster, graph dependencies, deploy in order, roll back, and export plain Kubernetes manifests.
Every compile produces concrete information you can inspect before the cluster changes.
A Kubernetes cluster is a system of relationships. Kix evaluates that system as one artifact before deployment, then emits standard resources for the delivery process you choose.
The output is concrete: checked, diffed, reviewed, deployed, rolled back, and tied to evidence.
Selectors, routes, ports, RBAC, storage, TLS, and monitoring wiring are checked before the cluster is touched.
Produce SARIF, SBOM, provenance, attestations, activation hashes, and audit evidence from the same evaluation.
Understand blast radius, deploy in order, reason about drift, and roll back with the graph in view.
Because Kix evaluates the cluster as one artifact, it can derive work teams usually maintain by hand: network policy, RBAC, monitoring wiring, ingress, ordering, repeated platform rules, and environment-specific variation.
Kix emits standard Kubernetes resources and can coexist with Helm, Argo, Flux, and existing CI. The benefits compound as more of the cluster moves into native Kix packages.
Compile a disposable cluster, inspect the graph and reports, deploy it, make a change, and roll back.
Start with a new cluster, selected subsystem, or imported resources that match what already runs.
Native packages expose richer structure, which unlocks stronger checks, generated wiring, and better operational tooling.
Kix comes from operating production Kubernetes infrastructure. The team behind it runs Lithus, a managed private-cloud provider operating dedicated bare-metal Kubernetes clusters in Germany, with migrations, observability, backups, SRE ownership, and incident response included.
Kix is the tooling we wanted for that work: cluster state that is testable, repeatable, explainable, and safer to change.
Kix turns your cluster definition into a verifiable artifact, so platform teams can understand, change, and operate Kubernetes with confidence.