Kairon
Inspect Kairon VMs, network policy and VM-edge flows from an agent. Read-only by default.
Runs on your machine from its package; the steps are below.
What it does
- Reads
- Writes
- High impact
Not assessed yet.
What it costs
FreeOdel charges nothing per call. The publisher may charge for its own service.
Runs locally over stdio
This server isn't hosted — your MCP client launches it from a package registry. Use one of the commands below, or drop the config into your client (e.g. Claude Desktop).
Run
docker run -i --rm ghcr.io/zyvorai/kairon-mcp:v0.10.2
MCP client config
{
"mcpServers": {
"kairon": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"ghcr.io/zyvorai/kairon-mcp:v0.10.2"
]
}
}
}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 → |
| Mac Fabric (experimental) | Several Macs as one pool: each publishes its chip, macOS, Rosetta, nested virtualization and Thunderbolt Bridge; spec.apple places vz Machines by them, and a MacNetwork gives Machines on different Macs one private network over Thunderbolt. Run against simulated Macs so far. Guide → |
| Cross-cluster DR (experimental) | A MachineProtectionPlan replicates a group of Machines to S3 and keeps their specs and restore points on a second cluster, with RPO and RTO objectives. kaironctl dr failover brings them up there in dependency order, --planned with nothing lost; kaironctl dr test restores copies into an isolated network while production runs, also on a schedule. Machines keep their VirtualNetwork addresses and DNS names follow the active site through external-dns. Guide → |
| vGPU profiles and GPU health (experimental) | spec.devices[].profile gives a Machine a slice of a GPU (NVIDIA vGPU or MIG-backed profile) instead of a whole one, scheduled by free instances and GPU memory, created when the Machine starts and returned when it stops; unhealthy GPUs are skipped. Guide → |
| Accelerator profiles (experimental) | A cluster-scoped MachineAcceleratorProfile names an accelerator shape (count, vendor or vGPU profile, memory per device, one PCIe root for peer to peer, one NUMA node, an RDMA NIC next to the GPUs); Machines ask for it with spec.accelerators. The profile's status says how many more Machines fit on each node. Guide → |
| Node maintenance and DRS (experimental) | kaironctl node maintenance enter NODE cordons a node, migrates its Machines away, and stops or hibernates the ones with nowhere to go; exit puts everything back. DRS (`-drs-mode recommend |
| Per-disk I/O QoS | IOPS and bandwidth limits on a Machine's root and data disks (io.throttle), with bursts, enforced by QEMU and changed live on a running Machine. Guide → |
| NVMe-oF storage (experimental) | Kairon's CSI driver provisions nvme-tcp and nvme-rdma volumes through the kernel NVMe target with native multipath; raw Block volumes boot Machines in place and attach as data disks with per-disk QEMU I/O. Guide → |
| Hibernate (experimental) | spec.powerState: Hibernated saves RAM and device state to disk and frees the node; resume continues the same boot, on its own node or a compatible one with shared storage. Guide → |
| Virtual networks (experimental) | VirtualNetwork: isolated IPv4 networks routed in eBPF with a Geneve overlay, per-network gateway, egress SNAT and floating IPs. Guide → |
| Elastic memory (experimental) | Run more Machine memory than the node has: guaranteed minimums, a virtio-balloon reclaim loop and a KaironMemoryPressure signal the scheduler respects. Guide → |
| Topology-aware placement (experimental) | NUMA, GPU, NIC and NVMe locality: the scheduler picks the node, exact CPUs, NUMA memory and PCI devices together. Guide → |
| Incident bundles (experimental) | kaironctl diagnose machine --deep: one redacted tar.gz with the Machine's cluster state plus QMP, cgroup, console, dataplane and pcap from its node, and an opt-in guest memory dump. Guide → |
| Lifecycle, diagnostics and namespaces (v0.9) | kaironctl doctor, connectivity test, logs, events, sysdump, config, history/rollback; kaironctl upgrade keeps your previous Helm values. The dashboard has a namespace selector, an all-namespaces Machines view and bulk Start/Stop. Release notes → |
v1 API and new dashboard | kairon.zyvor.dev/v1 is the storage version (v1beta1/v1alpha1 served, deprecated). The dashboard is redesigned and gains Storage (Atlas), Pools & claims, Images and Backups pages; kairon-ui now listens on :18082. Guide → |
| Native macOS node | kairon-node registers an Apple silicon Mac as a Node and runs backend: vz Machines through FluxVM. Verified on an M4; multi-Mac clusters not yet. Guide → · Mac cluster → |
| Developer ecosystem kit | Python and TypeScript SDKs, digest-pinned recipes, disposable-VM GitHub Actions, Terraform composition. Kit → |
| Fleet automation (experimental) | Opt-in Redfish fencing, balancing, autoscaling, backup and recovery plans, template claims, usage CSV and a Fleet dashboard. Guide → |
| Kairon vs KubeVirt benchmark | Same node, same guest, one script driving both; method and raw JSON in docs/benchmarks. |
| Import from VMware | kaironctl import ova streams an OVA once, reads vCPU, memory and firmware from the OVF, and FluxVM converts and repairs the disk. Guide → |
| Warm pools and claims | MachinePool keeps booted Machines ready; a MachineClaim binds one in a single reconcile tick, with per-claim egress allowlists. Guide → |
| VM fork | kaironctl fork and the MCP fork_machine tool fork a running Machine through FluxVM. Guide → |
| Agent sandboxes (experimental) | spec.lifecycle pauses idle Machines and wakes them on connect, deletes them after a max lifetime; paused warm pools, per-claim usage, and Sandbox classes in both SDKs. Guide → |
| Backups | MachineBackup and MachineBackupRestore with guest filesystem freeze, plus Atlas S3 backup jobs for Atlas volumes. Incremental S3 backups with policies and GFS retention (experimental). Guide → |
| Live disks and NICs | Hot-attach PVC disks and hot-add or remove extra NICs on running Machines (kaironctl disk, kaironctl nic). Guide → |
| Tenant fence | kairon.zyvor.dev/tenant-fence turns spec.tenant into an east-west deny of other tenants' guest addresses in the namespace. Guide → |
| Preemption by Halt | An opted-in high-priority Machine that can't be placed halts an opted-in lower-priority one, and it resumes when the preemptor leaves. Guide → |
| Hotplug survives restart | A stop/start boots at the hotplugged CPU and memory; hotplug-persist writes it back into spec. Guide → |
| Halted resume keeps hotplug | Resuming a Halted Machine hotplugs its CPU and memory back to the pre-halt size. Guide → |
| Claims carry the template | A createMachine pool claim gets the template's resources, kernel, cloud-init, NUMA, security, guest agents, TTL and forwards; anything not carried is listed in machineWarnings. Guide → |
| Daily snapshot schedules | dailyAt: "02:30", stable jitter and maxAgeSeconds retention on MachineSnapshotSchedule. Guide → |
| CPU-pinning discovery, deployed | deploy-remote.sh --reserved-cpus=0-1 or Helm node.cpuPinning gives kairon-node kubelet's CPU state, so pinnable-cpus is discovered. Guide → |
| Approval for agent actions | Destructive MCP tools wait for a single-use kaironctl approve. Guide → |
| Stale evacuation | Opt-in: Machines marked evacuate=true are fenced off a node attested dead with kaironctl node fence. Guide → |
| Image catalog and ISO installs | Cluster-scoped MachineImage (disk or ISO, pinned by digest), spec.cdroms install media on SATA, blank root disks, and seeding of empty boot volumes. No CDI. Guide → |
| OCI containerDisk | spec.image.source.oci pulls a disk image by digest with streaming per-layer verification. 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 |
| AI agents | MCP server built in (kaironctl mcp serve) | Not included |
| Browser console | noVNC relay with per-Machine allowlists and Kubernetes RBAC | virtctl vnc / external UI |
| Source of truth | The Kubernetes API, nothing else | Kubernetes plus virt abstractions |
| Install | One Helm chart from OCI, or kaironctl install | Operator plus CR, CDI for images |
| Choose KubeVirt when | You need its years of ecosystem integrations (OpenShift Virtualization, Harvester) today |
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
 Overview: fleet health and node usage |  Migrations, with NeedsRecovery surfaced |  All namespaces, bulk Start/Stop |
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
New in v0.10.0, animated: agent sessions, idle sandboxes, cross-cluster DR, maintenance and DRS, elastic memory, incremental backups, Mac Fabric
| 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.
From source, kind, or raw manifests
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.
| Next step | Where |
|---|---|
| First Machine, end to end | Getting started |
| Everything that ships | What ships |
| Every command | CLI reference |
| Hardware evidence | Compatibility matrix |
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
| Goal | Document |
|---|---|
| Getting started | docs/getting-started.md |
| What ships | docs/WHAT_SHIPS.md |
| Architecture | ARCHITECTURE.md · docs/architecture.md |
| Developer ecosystem | SDKs, templates, CI and integrations |
| AI agents and MCP | docs/ai-agents.md |
| Status and gaps | docs/STATUS.md |
| Hardware matrix | docs/COMPATIBILITY.md |
| Roadmap | ROADMAP.md |
| Security | SECURITY.md · OpenSSF |
| Contributing | CONTRIBUTING.md |
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 |
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: sales@zyvor.dev.
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 · sales@zyvor.dev.
Bugs and feature requests → GitHub Issues. Report vulnerabilities privately to security@zyvor.dev 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.
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.