Skip to main content

Roadmap

What kixctl does today​

Everything documented in these pages is shipped and proven on real hardware:

  • Fabric management — cluster overview; instances (create, lifecycle, rename, reconfigure, delete); snapshots; and managed networks and profiles, across one to a few nodes.
  • Push-to-deploy — a git push builds an immutable NixOS revision and launches it, from Forgejo, Gitea, Codeberg, or GitHub, by webhook or poll.
  • The full deploy lifecycle — update, cutover, revert, and reap from one tab, with pooled promotion for updating many apps at once.
  • Multi-cluster — manage more than one Incus cluster from one control plane, each over its own scoped certificate.
  • Access control — verb-level roles and user management.
  • The appliance, as a bootable VM image — released in v0.1.0 (pre-release). Boot the image on any hypervisor, and a first-run wizard sets it up: it stands up its own bridge, DNS, and edge from images baked at build time, with Incus invisible underneath. See Installing kixctl.

Where it is headed​

The roadmap is stated as sequence, not dates. The near-term priorities are the ones that change who can run kixctl and how easily:

  • A bare-metal installer ISO — the Proxmox-style "boot the media, it installs to disk, reboot into it" flow. The appliance VM image exists today; the install-to-disk ISO is the next distribution item, so a stranger can dedicate a box to it without a hypervisor.
  • Public distribution — hosting the multi-gigabyte appliance image somewhere a stranger can fetch it directly, and building it on tag so releases stay current.
  • A packaged bolt-on — a container or installable build you point at an Incus cluster you already run, so the bolt-on path stops requiring a from-source bring-up.
  • An interactive console — a browser terminal into any instance, permission-gated and inside the isolation boundary. It closes the one honest gap against a hands-on hypervisor without touching the no-shell rule in the control path: it is your shell into your own container, not kixctl's.
  • Richer observability — deeper per-node health, build-queue visibility, and capacity alerting.
  • Managed backups — scheduled, retained backups of what the state-boundary design already isolates as the thing worth backing up.
  • The provisioned-database tier — kixctl standing up a database container on your own cluster, the middle of the three-tier direction, over the same injected connection path.
  • An enterprise tier — single sign-on, fine-grained per-instance authorization enforced inside the hypervisor, and audit, for the organization whose security review requires them. Opt-in, never a baseline requirement.
  • LLM-ready operations — export instance state, logs, and events in a structured form an assistant can read directly, so the fleet stays legible to the tools people increasingly run it with.

What kixctl is not chasing​

kixctl is not trying to be a like-for-like replacement for a mature hypervisor, and it does not compete on the breadth of a one-click app catalog. Its unit is your app, built immutably and deployed with a clean rollback, across the clusters you run. Where a simpler tool fits — one app on one VPS, or a hypervisor with a decade of hardening for a pure virtualization checklist — it will tell you so.