Skip to main content

Requirements and the substrate

kixctl runs on Incus, and that is very nearly the whole of what it asks for.

What you need​

A running Incus. That is the list. 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 to Incus over a scoped credential — a Unix socket or a client certificate — 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. You bring Incus; kixctl brings the rest.

What you do not need​

  • No storage or networking to pre-build. kixctl provisions the pool, networks, and profiles it needs if they don't already exist — you don't set them up by hand first.
  • 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 fresh operating system on your hosts. Incus runs on the Linux you already have.

Is it for you?​

Standing kixctl up is not the barrier — Incus is a package install, and kixctl builds out the rest. 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.