Kairon

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):

Why Kairon

[Capabilities at a glance: Run, Move, Protect, Automate]

The numbers

[Kairon vs KubeVirt v1.9.0 on the same node: 14x less idle control-plane memory, 2.9x faster to SSH for one VM, 7.4x faster for five, the same memory per VM]

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

[Kairon vs KubeVirt: the same kubectl and KVM, half the stack in between]

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.

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 qemukaironctl 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 20kaironctl network drops demokaironctl network capture demo --seconds 15 --output demo.pcap

AI agents, safely

[Agent plane: AI proposes, Kairon validates. ask and diagnose feed strict compilers and validators, then a hash-chained audit log, then the cluster. Sealed claims, edge Warning events, per-Machine baseline anomaly scoring, cosign image verification, SEV-SNP/TDX attestation and audited MCP write tools]

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

[Selecting three Machines and stopping them together] [Switching namespace and filtering the Machines table]

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

[Two Go binaries and your KVM hosts: kairon-controller, kairon-node, FluxVM and KVM under the Kubernetes API]

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-amd64chmod +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-kaironmake docker-buildhelm upgrade --install kairon ./charts/kairon -n kairon-system --create-namespace# or: kaironctl install   (embedded Helm SDK, no helm binary needed)

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

# Relocatekaironctl migrate demo --strategy cold --target-node worker-2kaironctl migrate demo --strategy live --target-node worker-2 --mode pre-copykaironctl evacuate worker-1 --wait
# See the network from the VM's point of viewkaironctl network status demokaironctl network drop-reasons demokaironctl network identity demo
# Hand the fleet to an AI agentkaironctl 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:18082kaironctl ui                         # or through the API server, no port-forward

Maturity

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 gatemake build smoke                        # binaries and smoke testcd 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

→ 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.

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.

[Mac mini for home, Mac Studio for a team, MacBook Pro for development]

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.

[A private LLM cluster made of Macs]

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.