Kairon
VMs that don't pretend to be Pods.
Real virtual machines, scheduled by Kubernetes, run straight on KVM. No virt-launcher pod per VM, no libvirt in the hot path, no operator zoo. A Machine is desired state, kairon-controller places it, and kairon-node runs it on FluxVM with QEMU, Cloud Hypervisor, Firecracker or FluxVM's own hypervisor.
Zero pods per VM · Four hypervisors, one CRD · eBPF on every VM edge · No silent split-brain · AI agents built in (MCP)
Dashboard tour captured against the local sample-data stack (how), not a production cluster.
What's new
Experimental operations: Kairon Rehearsal tests upgrades on isolated CSI copies. Advanced operations adds health-gated configuration change plans, application recovery verification, traffic/RTT placement recommendations, and incident reproduction with fix verification. Includes runnable scenarios and failure-path tests. VM/CSI and host-isolation hardware qualification is still pending.
New since v0.6.0 (latest tag: v0.10.2; the rows down to incident bundles are new in v0.10.0):
| |
|---|
| Agent sessions (experimental) | An AgentSession is a FluxVM agent session: a sandbox VM with a git workspace, a compiled egress/filesystem/process policy, budgets, checkpoints, live forks and an event ledger, scheduled and quota-counted like a Machine. Commands can wait for an admin's approval; chunked uploads, an interactive shell, credential grants the guest never sees, and the Mac guest's screen. kaironctl session, session_* MCP tools, both SDKs and a dashboard page. Mac nodes on FluxVM 0.4.8+. Guide → |
| Coming from virtctl | kaironctl covers virtctl's verbs: console and VNC (with screenshots), restart/soft-reboot, exports and memory dumps, guest info, SSH keys and passwords, expose, freeze, guestfs, cdrom, create clone, objectgraph, --dry-run -o yaml, wait. CLI → |
| Self-test: is it all working? | kaironctl selftest (or the dashboard's Self-test page) boots a tiny CirrOS VM and proves power, network, hotplug, snapshot-restore and more, with live coloured logs and a PASS / FAIL / SKIP table. deploy-remote.sh --self-test runs it right after a deploy. Guide → |
| Deploy without building locally | deploy-remote.sh --remote-build copies a small source tarball and compiles on the host, so a laptop needs no Go, no Node and no build cache. Fastest path → |
| HTTPS by default | The dashboard and the VNC console relay serve TLS out of the box (generated or bring-your-own certificate); plain HTTP is a named opt-out. Dashboard guide → |
Why Kairon
| When this happens… | Kairon gives you… |
|---|
Every VM drags a virt-launcher pod, libvirt and a QEMU wrapper behind it | Nothing per VM but the VM. kairon-node talks to FluxVM's REST API, which talks to KVM. |
| A migration dies halfway and nobody knows which copy is real | NeedsRecovery. An ambiguous commit stops the line and asks a human; it never guesses and never runs two copies. |
| You need microVMs for CI and agents, but full VMs for databases | One Machine CRD, four hypervisors: QEMU, Cloud Hypervisor, Firecracker, FluxVM. Pick per Machine with spec.backend. |
| VM networking means Pod CNI tricks, masquerade and Multus | An eBPF edge on every VM tap: anti-spoofing, DNS and TLS-SNI policy, rate limits, flows, attributed drops and packet capture. |
| Debugging the control plane means reading a client-go codebase | Stdlib-only controller and node (dependency policy). Small enough to read in an afternoon. |
| Your AI agent needs to see and drive your fleet | kaironctl mcp serve: Machines, policies and live network data for Hermes Agent and any MCP client, writes gated behind --allow-write. Also published as the ghcr.io/zyvorai/kairon-mcp image and listed in the MCP Registry as io.github.zyvorai/kairon (v0.10.2) (install from the registry). |
The numbers
| Kairon | KubeVirt v1.9.0 | |
|---|
| Idle control plane memory | 63 MiB | 905 MiB | 14x less |
| 1 VM to SSH | 23.7 s | 67.6 s | 2.9x faster |
| 5 VMs to SSH, median | 24.8 s | 184.7 s | 7.4x faster |
| Memory per VM (5 VMs) | 660 MiB | 661 MiB | Even: same QEMU, same guest |
Same k3s node, same Ubuntu 24.04 image, same 1 vCPU / 512 MiB guest and cloud-init seed, one script driving both, ready meaning the guest's sshd answers. The VM costs the same either way; what you stop paying for is everything KubeVirt puts around it. Method, raw JSON and caveats (including the 10-VM run): docs/benchmarks.
Kairon vs KubeVirt
Every layer you remove is one less thing to patch, one less log to read and one less process to crash at 2 a.m.
| Kairon | KubeVirt |
|---|
| A VM is | A Machine: its own CRD, its own lifecycle | A Pod in disguise (virt-launcher) |
| Pods per running VM | 0 | 1 virt-launcher pod each |
| Idle control plane, 5 VMs to SSH (measured) | 63 MiB, 25 s | 905 MiB, 185 s |
| Path to KVM | kairon-node → FluxVM REST → KVM | virt-handler → virt-launcher → libvirt → QEMU |
| Hypervisors | QEMU, Cloud Hypervisor, Firecracker, FluxVM | QEMU via libvirt |
| MicroVMs and warm pools | Firecracker / FluxVM sandboxes, FluxVM warm pools (24 ms claim measured) | Not a target |
| Scheduling | Capacity-aware Kairon placement on real allocatable | Pod scheduler plus virt extras |
| Control plane code | Go standard library only (controller, node) | Large client-go / controller-runtime surface |
| VM network | eBPF VM edge: anti-spoof, DNS/SNI policy, rate limit, flows, drop reasons, pcap | Pod CNI, masquerade/bridge binding, Multus |
| Network policy | MachineNetworkPolicy + NetworkSecurityGroup, optional Cilium sync | Pod NetworkPolicy |
| Live migration | mTLS node-to-node prepare/commit/abort with an encrypted data plane | libvirt migration inside the virt stack |
| Ambiguous migration commit | NeedsRecovery: no silent split-brain | Stack-dependent recovery |
| Packet capture of one VM | kaironctl network capture demo --seconds 15 | Exec into the launcher pod and bring your own tools |
The previous layer-stack illustration: docs/assets/kairon-vs-kubevirt.jpg.
What you get
Machines, not Pods
Machine and MachineSet with instance types, NUMA and CPU pinning, Windows guests, PVC and CSI boot, multi-volume virtiofs, CPU/memory hotplug, pause and halt, cloud-init and port forwards. Desired state lives in Kubernetes; the node reconciles it every few seconds. What ships →
kaironctl create demo --image /var/lib/fluxvm/images/ubuntu.qcow2 --cpu 2 --memory 2Gi --backend qemu
kaironctl get machines
Migration that refuses to guess
Cold migration, node evacuation, and secure live migration over mutual TLS with an encrypted data plane. Cordon a node and the controller can evacuate it for you, throttled by MachineDisruptionBudget. When a commit is ambiguous the Machine goes to NeedsRecovery and waits for an operator instead of risking two running copies. Relocating → · NeedsRecovery runbook →
An eBPF edge on every VM
Each VM tap gets FluxVM's eBPF dataplane: anti-spoofing, DNS and TLS-SNI allowlists, rate limits, and drops attributed to a reason (spoof_ip, dns_deny, sni_deny, rate_limit, …). Write policy as MachineNetworkPolicy / NetworkSecurityGroup; see it live in the CLI and the dashboard Network panel; capture packets from one VM in one command. VM edge → · Network fabric →
kaironctl network flows demo --limit 20
kaironctl network drops demo
kaironctl network capture demo --seconds 15 --output demo.pcap
AI agents, safely
kaironctl mcp serve speaks the Model Context Protocol over stdio. Hermes Agent, Claude, Cursor or any MCP client can list Machines, read policies and pull flows, drops and captures. Power, snapshot, capture, sealed-claim and policy-apply tools only appear with --allow-write, and every write is recorded in a hash-chained audit log first. kaironctl agent ask turns a plain-English request into a validated proposal using any OpenAI-compatible model, and kaironctl agent diagnose ranks why a Machine or migration is stuck; neither applies anything, and no model runs in the reconcile loop. Covered end to end in CI with the official MCP SDK. AI agents → · Agent plane →
Snapshots and recovery
MachineSnapshot, MachineSnapshotRestore and MachineSnapshotSchedule on CSI VolumeSnapshots, with guest-agent filesystem freeze for application-consistent snapshots. VM memory snapshots through FluxVM, and CRD backup/restore scripts for disaster recovery. Snapshots →
Fleet guards and operations
MachineQuota, MachineDisruptionBudget, MigrationPolicy and an opt-in admission webhook. kairon-ui dashboard with SSO, per-operator accounts and an in-browser VNC console. Prometheus metrics and alerts, controller HA leases, opt-in OpenTelemetry spans. Observability → · Security →
The dashboard
More pages: gallery. Screenshots and clips are generated from the sample-data stack in docs/ux, so they show the real dashboard build, not a lab cluster.
How it fits together
| Component | Port | Role |
|---|
kairon-controller | :32301 health, :8443 webhook | Placement, migration state machine, fencing, snapshots, quotas and budgets |
kairon-node | :32302 health, :9443 mTLS peer, :8090 console | Per-host agent: FluxVM lifecycle, eBPF policy, live-migration peer, edge Warning events, confidential-capability label |
kairon-ui | :18082 (HTTPS) | Optional dashboard: Machines, migrations, snapshots, Storage (Atlas), Pools & claims, Images, Backups, Network panel, VNC console; see dashboard guide |
kaironctl | — | CLI and kubectl kairon plugin, embedded Helm installer, MCP server |
| FluxVM | 127.0.0.1:7788 | The VMM layer on each host: QEMU, Cloud Hypervisor, Firecracker, FluxVM |
flowchart TB
subgraph clients["Clients"]
cli["kaironctl / kubectl kairon"]
dash["Dashboard (HTTPS)"]
agent["AI agents via MCP"]
end
clients --> api["Kubernetes API<br/>Machine, MachineMigration, VirtualNetwork, ..."]
api <--> ctl["kairon-controller<br/>placement, migration state machine,<br/>quota, IPAM, backup policy"]
api <--> ui["kairon-ui"]
api <--> node["kairon-node<br/>one per VM host"]
node -->|"REST on 127.0.0.1"| flux["FluxVM<br/>QEMU, Cloud Hypervisor,<br/>Firecracker, FluxVM"]
flux --> kvm["KVM + eBPF edge"]
node <-->|"mTLS peer"| node2["kairon-node on another host"]
flux --> s3[("S3 backups")]
Full write-up: ARCHITECTURE.md · docs/architecture.md · architecture illustration: docs/assets/readme-architecture.jpg
Quickstart
On a Kubernetes cluster whose VM hosts run FluxVM:
kubectl label node worker-1 kairon.zyvor.dev/capable=true
helm upgrade --install kairon oci://ghcr.io/zyvorai/charts/kairon \
--version 0.10.2 -n kairon-system --create-namespace \
-f https://raw.githubusercontent.com/zyvorai/kairon/v0.10.2/charts/kairon/values-production.yaml
curl -fsSL -o kaironctl https://github.com/zyvorai/kairon/releases/download/v0.10.2/kaironctl-linux-amd64
chmod +x kaironctl && sudo mv kaironctl /usr/local/bin/ # or: kubectl krew install kairon
kaironctl create demo --image /var/lib/fluxvm/images/ubuntu.qcow2 --cpu 2 --memory 2Gi
The production profile pins image tags to Chart.AppVersion and turns on the webhook, namespace isolation, network default-deny and migration data-plane TLS. Images: ghcr.io/zyvorai/kairon-{controller,node,ui}, signed with checksums and SBOM.
From your laptop to a bare-metal host, built on the host so your laptop needs no Go or Node, with a smoke test at the end:
./scripts/deploy-remote.sh user@host --remote-build --with-controller --with-ui --with-console --self-test=quick
Without --remote-build the binaries are cross-compiled locally and shipped as static files. Either way the dashboard and the console relay are HTTPS. All flags and the deploy flow →
Then, on any install: kaironctl doctor checks the control plane and kaironctl selftest boots a CirrOS VM to prove it end to end.
git clone https://github.com/zyvorai/zyvor-kairon.git && cd zyvor-kairon
make docker-build
helm upgrade --install kairon ./charts/kairon -n kairon-system --create-namespace
# or: kaironctl install (embedded Helm SDK, no helm binary needed)
Raw manifests: kubectl apply -f deploy/crd.yaml -f deploy/rbac.yaml -f deploy/controller.yaml -f deploy/node.yaml, plus deploy/ui.yaml for the dashboard and deploy/rbac-cbt-backup.yaml only if you enable incremental S3 backups.
Requirements
- A Kubernetes cluster whose VM hosts are Linux with
/dev/kvm.
- FluxVM on each VM host (default
127.0.0.1:7788).
- For the eBPF edge: a kernel with BTF and cgroup v2, and
dataplaneMode: ebpf.
Operate
# Relocate
kaironctl migrate demo --strategy cold --target-node worker-2
kaironctl migrate demo --strategy live --target-node worker-2 --mode pre-copy
kaironctl evacuate worker-1 --wait
# See the network from the VM's point of view
kaironctl network status demo
kaironctl network drop-reasons demo
kaironctl network identity demo
# Hand the fleet to an AI agent
kaironctl mcp serve # add --allow-write for power, snapshot, capture and claims (audited)
kaironctl agent diagnose machine/demo # ranked causes; adds a model summary when KAIRON_LLM_URL is set
# Dashboard (HTTPS; self-signed unless ui.tls.secretName is set)
kubectl -n kairon-system port-forward svc/kairon-ui 18082:18082 # then https://localhost:18082
kaironctl ui # or through the API server, no port-forward
Maturity
| Area | Status |
|---|
Machine lifecycle, MachineSet, instance types, quotas, budgets | Stable |
| Capacity-aware scheduling, node-scoped watches, controller HA | Stable |
| Cold migration and evacuation | Stable |
Secure live migration and NeedsRecovery | Preview, two-host lab run 2026-10-14, both directions on matched QEMU; NeedsRecovery drill passed 5 of 6 runs, one unexplained failure; not yet in nightly CI (COMPATIBILITY) |
| Adaptive live migration (auto-converge, post-copy switch, zstd) | Experimental, adaptive lab cases passed on a two-host lab 2026-10-14, nightly workflow not yet (COMPATIBILITY) |
| eBPF VM edge, flows, drops, capture | Preview, single-host lab green |
| CSI snapshots with guest quiesce | Stable |
kairon-ui with SSO and VNC console | Stable |
| MCP server for AI agents | Preview, CI end-to-end with the official SDK |
| CPU/memory hotplug | Grow-only (QEMU) |
v0.10.2 is the latest release (a patch on v0.10.1 that fixes the release pipeline; v0.10.1 added the MCP server image and the MCP Registry listing). Two-host live migration ran on a real lab on 2026-10-14 (cold, source failure, controller failover, all three adaptive cases and post-copy source failure pass in both directions on matched QEMU 10.2.1; plain pre-copy under a heavy write load did not converge, and the NeedsRecovery drill passed 5 of 6 runs with one unexplained failure that left a migration in Adopting). There is no live + eBPF run and no nightly CI yet, so it stays Preview. Adaptive live migration stays Experimental until its matrix cases pass on the nightly lab workflow. Honest gaps live in docs/STATUS.md; what comes next is in ROADMAP.md.
Docs
Develop
make test-race && make cover-check # Go tests with the race detector, coverage gate
make build smoke # binaries and smoke test
cd web && npm install && npm run dev # dashboard UI
Start with CONTRIBUTING.md; the dependency rules are in docs/DEPENDENCIES.md.
Part of the Zyvor stack
| Product | Role next to Kairon |
|---|
| Kairon | VMs on Kubernetes without KubeVirt |
| FluxVM | The VMM layer Kairon runs on: QEMU, Cloud Hypervisor, Firecracker and its own hypervisor, eBPF VM edge, sandboxes, fork |
| Atlas | Storage: kairon-controller provisions Machine volumes, snapshots and S3 backups through Atlas |
| Machina | Private cloud on plain Linux + KVM: fleet, HA/DRS, Fleet Cloud, native eBPF, Zyra AI |
| GuestKit | Pairs with Kairon: in-guest agent, offline inspection and repair, per-container eBPF policy |
→ zyvor.dev
Support
Free under Apache-2.0. If it helps you, you can donate any amount you like: https://rzp.io/rzp/utwdYh3. A donation is voluntary and supports development and maintenance. It is not a purchase: it buys no support, SLA, features, priority or license, and it is not tax-deductible (Zyvor AI Labs Private Limited is a company, not a charity). Zyvor Enterprise (supported releases, SLAs, a named contact and enterprise features) is separate: [email protected].
License
Kairon is free and open source under the Apache License 2.0 (see NOTICE): use, modify and run it in production at no charge. That does not change.
Zyvor Enterprise adds what production teams ask for: supported releases, deployment and upgrade guidance, priority incident triage, a named technical contact and 24x7 critical intake. Plans and terms: docs/SUBSCRIPTION-MODEL.md · Pricing · [email protected].
Bugs and feature requests → GitHub Issues. Report vulnerabilities privately to [email protected] or via GitHub private vulnerability reporting; see SECURITY.md. Contributions: CONTRIBUTING.md.
Ready to retire virt-launcher?
Native macOS
Kairon builds and runs natively on Apple silicon and can schedule Machines onto a Mac through FluxVM's vz backend. See docs/macos.md for what is verified and the limits.
Every Mac becomes a Kubernetes Node: a Mac mini at home, a Mac Studio for a team, a MacBook Pro that comes and goes. Kairon places Machines by allocatable unified memory, FluxVM runs them, and Velora serves private OpenAI-compatible LLM endpoints on the same hardware. A few Mac Studios become a quiet, low-power, on-premise inference cluster.
Verified on an Apple M4, macOS 27.2: a Mac registered as a Ready Node, a vz Machine scheduled, booted, SSH, deleted. Not yet verified: multi-Mac clusters, Thunderbolt RDMA. Cluster guide with a multi-Mac example (examples/macos-fleet.yaml), sizing and roadmap, after GK Servis's Mac Studio case study: docs/macos-cluster.md.
