Product · VMs on Kubernetes · Zyvor Production License
Real VMs. No pods pretending.
Veyron is the command center for virtual machines on Kubernetes: one console, one API and one CLI, with every VM running straight on KVM.
Veyron
Real VMs on Kubernetes. No pods pretending. Running VMs on Kubernetes usually means wrapping every VM in a pod: a scheduler round-trip, an image pull, a launcher container and libvirt on the path to every boot, plus a separate UI for day two. Veyron gives you one console, API and CLI, and runs every VM straight on KVM.
What you get
Zero pods per VM
A VM is its own Kubernetes resource, started by the Kairon engine on FluxVM and KVM, with no libvirt in the way.
Templates and a console
Pick a current OS, size it, boot it and open its screen in the browser, or do the same from the API or CLI.
Day-2 ops built in
Hotplug, bulk actions, node maintenance, guest patching, snapshots, backups and self-healing as buttons and API calls.
Secured by default
Admin, write and read-only roles, OIDC single sign-on and a built-in SOC that flags exposed VMs.
Built for production
The VM command center: Veyron is what you touch, Kairon and FluxVM run the VMs, and Atlas, Kryton, PacketWolf and GuestKit plug in for storage, lab machines, network and in-guest repair.
Why teams choose us
- Measured against KubeVirt on the same node: a 14x lighter idle control plane and 7.4x faster to SSH with five VMs starting at once
- Four hypervisors behind one engine: QEMU/KVM, Cloud Hypervisor, Firecracker and FluxVM’s own
- Keeps no database: VM state lives in Kubernetes, and anything the engine cannot do returns a clear reason instead of a fake success
When to choose
- You want VMs and containers on one Kubernetes cluster without a pod wrapped around every VM
- Your team needs self-service VMs, day-2 operations and security checks in one console instead of scripts and YAML
Veyron questions
How it works
veyron create demo --template ubuntu-24.04Migrate from the platforms you already run
- Enterprise Hypervisors
- HCI Platforms
- AWS
- Azure
- Google Cloud
- Windows Hypervisor
- Oracle Cloud
- Machina fleet cloud
- KubeVirt
- KVM
- KVM-based Platforms
Measured
Pod-per-VM is the bottleneck. Veyron removes it.
The engine under Veyron, measured back to back against KubeVirt on the same node.
14x
lighter idle control plane
63 MiB vs 905 MiB
7.4x
faster to SSH, five VMs at once
24.8 s vs 184.7 s (p50)
10 of 10
VMs up, ten at once
KubeVirt: 0 of 10 in 600 s
Same node, same Ubuntu 24.04 guest at 1 vCPU and 512 MiB, same SSH readiness probe, one script. Per-VM memory is the same (both run QEMU), and the ten-VM run was on a shared lab host. Method and raw data.
How it works
One click in the console. Straight to KVM.
Nothing sits between the guest and the hardware except the hypervisor you chose.
Veyron
What you touch. Console, API and CLI turn “Ubuntu, medium” into a running machine.
Kubernetes
The source of truth. Machine resources, RBAC and settings, with no extra database.
Kairon
The VM engine. Places each machine on real capacity and runs it with an eBPF edge.
FluxVM
One REST API per host for four hypervisors, with a vsock guest agent instead of SSH.
Your hypervisor
QEMU/KVM for full VMs and Windows, Cloud Hypervisor, Firecracker microVMs or FluxVM’s own.
KVM
Linux KVM on your hardware, GPU passthrough included.
| Veyron | KubeVirt | |
|---|---|---|
| A VM is | Its own Machine resource | A pod in disguise |
| Pods per running VM | 0 | 1 |
| libvirt on the boot path | No | Yes |
| Hypervisors | QEMU, Cloud Hypervisor, Firecracker, FluxVM | QEMU |
| One VM, create to SSH | 23.7 s | 67.6 s |
| Console, day-2 and SOC | Built in | Bring your own |
Capabilities
Run. Protect. Observe. Secure.
Everything a VM fleet needs after day one, in the same console that created it.
Templates and a console
Pick Ubuntu, Debian, Fedora, Enterprise Linux or Windows, size it, boot it, then open its screen in the browser.
Day 2 as buttons
CPU and memory hotplug, bulk actions, node maintenance, guest patching, disk reclaim and self-healing.
Undo for bad days
Snapshots, clones, backups and DR failback, plus Ceph snapshots and off-cluster backups through Atlas.
GPU and Windows, done right
Whole-GPU passthrough with a live-migration guard, and Windows golden images with unattended setup and safe RDP.
Roles, not a shared password
Admin, write and read-only roles, scoped keys, local accounts and OIDC from Keycloak, Okta, Auth0 or Azure AD.
A SOC that watches the fleet
Detections for public RDP and SSH, policy gaps and drift, exported to Elastic, Splunk, Sentinel or QRadar.
In the console
Everything in one place
Mega-menus, a ⌘K palette for everything, a live fleet map and a details panel on every row.
Deploy
Two commands to your first VM
On a Kubernetes cluster whose VM hosts run Kairon. k3s works well.
git clone https://github.com/zyvorai/veyron.git && cd veyron ./scripts/deploy-remote.sh <node-host> <ssh-user> # Open https://<node-ip>:30151/console and sign in
# The same VM from the API or the CLI
curl -sk -H "X-API-Key: $VEYRON_API_KEY" -H 'Content-Type: application/json' \
-X POST https://<node-ip>:30151/api/v1/vms \
-d '{"name":"demo","template":"ubuntu-24.04","cpus":2,"memory":"4Gi"}'
veyron create demo --template ubuntu-24.04 --cpus 2 --memory 4GiFree for evaluation and other non-production use; production needs a commercial license. Getting started · product guide · README.
Run your VM fleet from one place.
Book a demo or start a 30-day proof of concept on your own hardware.