Frequently asked questions

Honest answers to the questions that come up when people are deciding whether kixctl fits. Where something isn't built yet, this page says so.

How is kixctl different from Proxmox?

They overlap less than the comparison suggests. Proxmox virtualizes hardware you own — run any operating system, manage it by hand, with a mature GUI. kixctl bolts onto an Incus fabric and adds the layer Proxmox has no concept of: an application you deploy immutably, roll back in one action, and manage across clusters, behind a control plane that can't escalate its own access. For everything else — running instances of any distro and managing them by hand — it behaves much like the hypervisor you already know. See kixctl vs Proxmox.

Do I have to learn NixOS to use it?

No — and this is the part worth being clear about. Running instances works like any hypervisor: create one from any distribution in the Incus image catalog — Debian, Ubuntu, Alma, whatever — then log in and use apt or dnf exactly as you would on a cloud VM. NixOS enters in one place only: the immutable application-deploy path. When you push a git repository, kixctl builds it into a NixOS image so it can roll back to an intact previous revision — and even then you don't write Nix, you add a short kixctl.app block. Pick a distro and run it normally, or opt into the immutable deploy path per application. NixOS is the engine behind rollback, not a substrate you have to adopt. See Your first deploy.

What do I need to run kixctl today?

An Incus fabric. kixctl bolts onto an existing Incus cluster — a single node is fine — and drives it over a scoped credential, never as host root. A copy-on-write storage pool (btrfs) is what makes snapshots and revisions instant. You do not have to run NixOS on your hosts: the immutable-deploy path produces NixOS images that run as instances on whatever fabric you have. A future appliance will ship the whole substrate as a bootable image for people who'd rather not assemble it — convenience, not a requirement. See Requirements and the substrate.

Can I run it on one box, or do I need a cluster?

One box is fine. kixctl runs from a single node to a few, and manages one cluster or several from the same control plane — you don't need a large cluster to get value from it.

What happens to my data when I roll back?

Nothing. Rollback reverts an instance or application to a previous revision, but the state you keep outside the image — databases, persistent volumes — lives outside the rollback boundary and survives untouched. This state boundary is the same principle the whole deploy lifecycle is built on. See Rollback and the state boundary.

Does "immutable" mean I can't change anything?

No. Immutability is opt-in and applies to the git-push application path: you change an app by deploying a new revision, not by editing a running one, and because each revision is a whole image, a rollback is a clean swap to an intact previous one rather than a restore you hope succeeds. Instances you create directly are ordinary Incus instances — log in, apt or dnf, change them as you like. See Immutable deploys.

Can I spin up a throwaway instance to try something, and undo it?

Yes. Create an instance from the image catalog in the distro you want, log in and install whatever you're testing, snapshot it before you go further, and restore to that snapshot to undo — effectively instant on copy-on-write storage. The root reverts; data on attached volumes survives. See Manage instances and Snapshots.

Can I get a shell into an instance?

Yes — an instance you create is a normal instance, so you reach it the way you'd reach any cloud VM, from the CLI. What's on the roadmap is an in-app browser console, so you can drop into a terminal from the dashboard without leaving it. The console stays inside the isolation boundary and doesn't change kixctl's rule that there is no shell in its own control path.

How does kixctl get my code?

Fetching is SSH-first: a private repository reached over ssh:// authenticates through the access the host already has, so kixctl stores no deploy key or token at rest. It learns of new commits either from a webhook you point at it — with the secret held encrypted — or by polling on an interval you set. It works with Forgejo, Gitea, Codeberg, and GitHub. See Your first deploy.

If the control plane is compromised, can it take over my infrastructure?

No. kixctl drives the fabric over a scoped client certificate it cannot widen, and there is no shell anywhere in its path — every action is a structured API call. So it cannot grant itself more access to your infrastructure than the credential it was issued carries. That's a property of how it's built, not a policy layered on afterward. See How kixctl connects to Incus.

Can I run Windows VMs or pass through a GPU?

kixctl creates both virtual machines and system containers, but mature Windows tooling and GPU or PCI passthrough are Proxmox's strengths today, not kixctl's focus. If that's your need, run Proxmox — or run it alongside kixctl, which handles the immutable application layer. See kixctl vs Proxmox.

How are backups handled?

By design, your state lives outside the image — which is exactly the thing worth backing up. Today you back that state up with your own tooling; managed, scheduled backups of the state boundary are on the roadmap. The immutable images themselves don't need backing up, because they rebuild reproducibly from a commit.

Is kixctl free?

Yes. kixctl is released under the AGPL-3.0-or-later license and is free to run. A commercial license is available for organizations that can't meet the AGPL's terms, and a paid enterprise tier — single sign-on, audit, per-instance authorization — is planned. See the roadmap.

Is kixctl production-ready?

kixctl is in active development and pre-release, and this page won't pretend otherwise. What's shipped and working: fabric and instance management, immutable push-to-deploy, the full deploy lifecycle (update, cutover, revert, reap), multi-cluster from one control plane, and verb-level access control. On the roadmap: the appliance, managed backups, richer observability, and the enterprise tier. Run it where an immutable, reversible application layer is what you need; weigh the roadmap against a pure-virtualization checklist that a mature hypervisor already ticks.