Skip to main content

Requirements and the substrate

kixctl asks for very little, and exactly what it asks for depends on which way you run it (see Installing kixctl for the two shapes).

If you run the appliance​

A machine to boot the image. That is the list. It can be a physical box or a virtual machine on any hypervisor. The appliance brings its own Incus, storage pool, networks, and profiles — you do not install or configure Incus at all.

A sensible target: 64-bit UEFI firmware, ≥ 4 vCPU, ≥ 4 GB RAM, and a disk with headroom (the root filesystem auto-grows to fill it on first boot). Nested virtualization on the host matters only if you want the appliance to run nested VMs; system-container workloads don't need it.

If you bolt onto your own Incus​

A running Incus. A single node is enough; three lean nodes is the design center. kixctl is not built for large fleets, and that is a design decision, not a limitation being apologized for. It connects over a scoped credential — a Unix socket on a cluster member, or a restricted, project-scoped client certificate from elsewhere — never as the host's root user.

If the storage pool, networks, or profiles kixctl needs aren't already there, it creates them from inside the app, and it records references to the ones you already run without touching them. You bring Incus; kixctl brings the rest.

What you never need (either way)​

  • No NixOS to learn or run. Instances you create are any distribution in the Incus catalog — Debian, Ubuntu, Alma, whatever — and you run them exactly as you would a cloud VM: log in, apt or dnf, manage them by hand. NixOS appears in one place only, and only if you want it: the immutable application-deploy path, where kixctl builds your repository into a NixOS image so it can roll back to an intact previous revision. Even there you write no Nix — a short kixctl.app block is the whole of it. NixOS is the engine behind rollback, not a substrate you adopt.
  • No storage or networking to pre-build. The pool, networks, and profiles kixctl needs are provisioned for you if they don't already exist.
  • No fresh operating system on your own hosts (bolt-on). Incus runs on the Linux you already have.

Is it for you?​

Standing kixctl up is not the barrier — the appliance boots, and the bolt-on builds out the rest on an Incus you already run. The honest question is fit, not effort.

If what you want is to deploy one app to one cheap VPS tonight, kixctl is the wrong tool and will tell you so — reach for something like Coolify. kixctl is opinionated toward a fabric you run over time: several workloads, real isolation between them, and deploys you can reverse. What that opinionation buys is the isolation boundary and the reproducible, revertible deploys described in Concepts — a real virtualization line under every workload, and a rollback that stands an intact previous revision back up rather than hoping a migration reverses. For infrastructure you intend to run and trust, that is the point.