Why kixctl

Put the field on two axes. One is whether a tool runs and isolates a real virtualization fabric — VMs, system containers, a genuine hypervisor boundary. The other is whether it deploys applications from git. Hypervisors sit far out on the first axis and at zero on the second. Self-hosted PaaS tools sit out on the second and near zero on the first. The corner that is strong on both is empty. That corner is what kixctl is built to occupy.

What you get here that you don't elsewhere

Isolation that survives a security review. Workloads run as Incus system containers or full VMs, not as containers sharing the host kernel. For your own code on your own box, a shared kernel is fine. For multiple customers, less-trusted code, or anything with a compliance boundary, it is exactly what a review flags.

Immutability that is real, not aspirational. A deploy produces an immutable NixOS image with state kept outside it. Rollback stands the previous revision back up, rather than redeploying an image onto a host that has drifted since. It is the difference between rolling back the code and rolling back and hoping.

A control plane that cannot escalate. The management layer is the internet-adjacent target in any system that can launch workloads. kixctl connects to the fabric over a scoped credential it cannot widen, so even a compromised control plane cannot grant itself more of your infrastructure.

Where kixctl is not the answer

If you want a like-for-like ESXi replacement with a decade of hardening and a support contract, run Proxmox — it won that migration and deserved to. If you want to deploy one app to one cheap VPS tonight with no knowledge of the substrate, run Coolify or Kamal. kixctl is narrower and more opinionated than either, on purpose: it runs on an Incus fabric and ships every application as an immutable, revertible image, and that opinion is what buys the isolation and the reproducible rollback. Naming who it isn't for is the thing that makes the rest of the case trustworthy.