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.

Where it is headed​

The roadmap is stated as sequence, not dates. The near-term priority is the one that changes who can run kixctl:

  • The appliance — the headline. Boot an image, kixctl installs itself, a first-run wizard sets it up, and Incus sits invisible underneath. It removes the substrate as an adoption cost, and it is built on the same image machinery already proven for application deploys. This is the priority, not a wish-list item.
  • 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.