# What is kixctl

kixctl is an open control plane for operators who run their own infrastructure. It manages an [Incus](https://linuxcontainers.org/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.