kixctl vs Proxmox
Proxmox runs your VMs. kixctl runs your apps. Proxmox hands you a virtual machine and a toolbox — then you deploy your app onto it by hand, every time, with no clean undo. kixctl makes the app the unit:
git push, and it's built into an isolated machine, booted, named, and reversible in one click. Only want to hand-manage VMs? Run Proxmox — we mean that.
kixctl and Proxmox both run containers and virtual machines on hardware you own. The difference is what happens after you have one. If you're shopping for a Proxmox alternative because it feels capable but cluttered, or because you want a real deploy story on your own metal instead of hand-managing every box, that after-you-have-one gap is the whole reason kixctl exists.
Proxmox hands you the instance and a mature toolbox to run it by hand — a decade-hardened GUI, any guest operating system, storage and networking you manage yourself. kixctl gives you the same create-run-snapshot-restore controls over an instance, and then adds the layer Proxmox has no concept of: an application you deploy immutably, roll back in a single action, and manage across clusters — behind a control plane that cannot escalate its own access to your fabric.
Neither is a strict upgrade on the other. Pick by the problem you actually have.
Why people run Proxmox
Proxmox VE is a mature, open-source (AGPLv3) type-1 hypervisor built on Debian, and it earns its reputation. It runs KVM virtual machines and LXC containers side by side, clusters across nodes with high availability and live migration, and offers software-defined storage through ZFS and Ceph. It backs up and restores through Proxmox Backup Server, passes through GPUs, and runs Windows guests. A decade of hardening, a large community, and a web GUI that does nearly everything without leaving the browser — and because it's Debian underneath, you can always SSH in and run anything.
Where Proxmox leads is breadth and maturity: the widest hardware and guest-OS support, mature GPU-passthrough and Windows tooling, storage you manage yourself, live migration and HA, and a decade of hands-on tooling. If that manual, run-anything surface is what you want, Proxmox is the mature choice.
What kixctl gives you
kixctl is not only an app-deploy tool. From the dashboard you already:
- Create and run instances — system containers or virtual machines — from a live image catalog: choose the node, the image, CPU and memory, and nesting, then start, stop, reconfigure, rename, and delete them, each verb its own permission. See Manage instances.
- Snapshot and restore any instance, effectively instant on copy-on-write storage. Break something while experimenting, restore to the snapshot, and you're back — the root reverts while data on persistent volumes survives. See Snapshot, restore, and delete.
On top of that instance layer is the part a general hypervisor doesn't attempt:
- Immutable deploys with instant rollback. Push a commit; kixctl builds an immutable NixOS image pinned to it and launches it as a new revision beside the running one. Roll back and the previous revision is a whole, intact machine — not a restore you hope succeeds. See Immutable deploys and Rollback and the state boundary.
- A control plane that cannot escalate. kixctl drives the fabric over a scoped certificate it cannot widen, with no shell anywhere in its path — so even a compromised control plane can't grant itself more of your infrastructure. Proxmox's root-capable GUI draws no such line. See How kixctl connects to Incus.
The trade is real and worth stating: you give up the run-anything breadth of a general hypervisor. In return you get a deploy-and-recover story, and a security boundary, that Proxmox doesn't offer.
What immutability does — and does not — cover
Worth being exact, because it's the heart of the pitch. Immutability and clean rollback apply to applications you deploy through kixctl — the NixOS image revisions it builds. It is not a claim that everything on the box is frozen. Launch an instance, open a session into it, and change it by hand, and you've stepped outside that boundary — that's ordinary instance work, not the immutable deploy path. The value is precisely that your app deploys become immutable and reversible, not that the universe is.
The substrate question: do I have to learn NixOS?
No — and it's worth being exact about why. Running instances works like any hypervisor: create one from any distribution in the Incus catalog — Debian, Ubuntu, whatever — and run it exactly as you would a cloud VM, apt or dnf and all. NixOS enters in one place only: the immutable application-deploy path. Push a repository with a short kixctl.app block — language, source, entrypoint, port — and kixctl builds it into a NixOS image so it can roll back cleanly, and you write no Nix yourself. See Your first deploy.
Setup is light, too, and it comes two ways. Bolt kixctl onto an Incus cluster you already run, and it creates the storage and networking it needs. Or run the appliance — available today as a bootable VM image — which brings its own Incus and asks nothing of you but a machine to boot it, Incus invisible underneath. Either way you're not learning a new operating system. See Installing kixctl.
Side by side
Legend: ✓ available today · Coming soon on the roadmap · ✗ not available or not a goal · Preview in tech-preview upstream.
| Capability | Proxmox VE | kixctl |
|---|---|---|
| Create, run, reconfigure instances from a GUI | ✓ | ✓ |
| Instant snapshot and restore (revert a broken instance) | ✓ | ✓ |
| Immutable application revisions | ✗ | ✓ |
| One-action rollback to an intact previous revision | ✗ | ✓ |
| Git-push deploy — image built from a commit | ✗ | ✓ |
| Config and secrets injected; state kept outside the image | ✗ | ✓ |
| Control plane that cannot escalate its own access | ✗ | ✓ |
| Manage multiple clusters from one control plane | Preview | ✓ |
| Turnkey appliance image (brings its own Incus) | ✗ | ✓ VM image · installer ISO coming soon |
| LLM-ready export of logs and instance state | ✗ | Coming soon |
| Virtual machines and system containers | ✓ | ✓ |
| GPU / PCI passthrough and mature Windows tooling | ✓ | ✗ |
| Software-defined storage (ZFS, Ceph) | ✓ | ✗ — delegated to Incus / the host |
| Live migration and HA clustering | ✓ | ✗ |
| Interactive console / terminal into an instance | ✓ | Coming soon |
Full manual host control (SSH, apt, run anything) | ✓ | ✗ — immutable by design |
| Mature backup and restore (Proxmox Backup Server) | ✓ | Coming soon |
| Decade-hardened, mature web GUI | ✓ | Newer dashboard |
| One-click app / template catalog | ✓ | ✗ — not chasing |
Both are AGPLv3 and free to run; both offer a paid path — Proxmox sells support subscriptions and an enterprise repository, kixctl has a commercial license and a planned enterprise tier (SSO, audit, per-instance authorization).
Which should you run?
Choose Proxmox for the established, general-purpose, hands-on approach: the broadest hardware and guest-OS support, mature Windows and GPU passthrough, storage you assemble and manage yourself, live migration and HA, and a host you drive by hand. It is mature and proven, and it won the ESXi migration for good reasons.
Choose kixctl for the modern one. Its unit is your workload — containers and VMs you create, snapshot, and restore, with an immutable deploy layer and one-action rollback on top, managed across every cluster from a single control plane that is built so it cannot be turned against your fabric. Where Proxmox gives you a box and a decade of manual tooling, kixctl automates the parts you shouldn't have to think about and makes the risky ones — deploys, upgrades, recovery — reversible by default. Run it as the appliance and it is the whole substrate rather than a layer you assemble by hand.
The short version: Proxmox is the hypervisor you operate; kixctl is the platform that operates your applications for you. If you're weighing the substrate itself, see kixctl and Incus.