What is kixctl

kixctl is an open control plane for operators who run their own infrastructure. It manages an Incus virtualization fabric — the clusters, nodes, and instances — and it deploys your applications onto that fabric immutably, from the same dashboard, across every cluster you touch.

Most tools in this space pick one side. A hypervisor manages the fabric but has no notion of shipping your app onto it. A self-hosted PaaS deploys your app but assumes a single box and a shared Docker kernel underneath. kixctl is built for the operator who wants both, without gluing two unrelated tools together.

The model

An application is built into an immutable NixOS image with the app baked in, and it runs as an Incus system container — a stronger isolation boundary than a container sharing the host kernel — or as a full VM when you need one. State that has to survive is kept deliberately outside that image. A new deploy builds a new revision alongside the one already running; promotion is a cutover you decide to make, and rollback stands the previous revision back up and swings traffic to it. The old revision is a whole, intact machine, not a hoped-for reverse migration.

Because every revision is an immutable image with a content-addressed fingerprint, what is running and what it came from is legible from the infrastructure itself, rather than tracked in a layer bolted on beside it.

How it runs

kixctl runs on an Incus fabric and talks to Incus over a Unix socket or a scoped client certificate — never as the host root. It cannot raise its own level of access to the fabric; that boundary is an invariant of how it connects, not a promise in a policy document. It is the property that lets the control plane be put in front of a security review.