Skip to main content

FluxVM

Secure, isolated virtual machines — via Firecracker, Cloud Hypervisor, QEMU/KVM, or the in-tree FluxVM hypervisor — from one Rust-native control plane with a real REST API. Run it standalone as a libvirt replacement, or as the VM engine under another Zyvor product. Use optional TTL and CoW when you want disposable compute; longer-lived guests use the same API.

Get StartedView on GitHub

Why FluxVM

Teams that need a host-local VM control plane — CI runners, sandboxed code execution, per-branch environments, Kubernetes VM workloads, or longer-lived guests — are usually stuck choosing between manual libvirt/virsh scripting (XML, no REST API, no built-in TTL cleanup), a full private-cloud platform (disproportionate overhead when you only need a solid VM API), or container-only isolation (fine until the workload needs a real kernel boundary).

FluxVM fills that gap: a Rust-native control plane with a real API, no libvirtd, no XML domain definitions — fluxctl create ≈ virsh define+start, fluxctl delete ≈ virsh destroy, plus optional TTL-guaranteed cleanup when you want disposable compute.

Four backends, one control plane

QEMU/KVM, Cloud Hypervisor, Firecracker, and the in-tree FluxVM hypervisor behind one VmBackend trait, with "backend":"auto" resolution and a vsock guest agent that needs no SSH.

Host-local libvirt replacement

No libvirtd, no XML domain definitions — a direct command mapping (fluxctl create ≈ virsh define+start, fluxctl delete ≈ virsh destroy) plus a real REST API libvirt doesn't have.

Network Fabric (GA, schema v4)

TC/eBPF or Cilium-coexistence VM-edge dataplane — IPv4/IPv6 L3+L4 policy, per-VM rate limits, security groups, live reconfigure, and REST observability, nftables as the default fallback.

Kubernetes-native, without KubeVirt

The DisposableVm CRD (verified end to end against a real k3s cluster, 9/9 checks) and the scheduler-native MicroVM path — a different, lighter model than KubeVirt, not a clone of it.

Optional TTL cleanup

ttl_seconds on a VM spec means a forgotten or crashed job still gets torn down when you opt in. Combined with the Firecracker jailer, cgroup v2, and network.mode:"none", this supports disposable / sandboxed execution without defining the whole product.

Multi-host fleets, no Kubernetes required

fluxvm-agent is a central fleet registry plus per-host heartbeat client with load-aware placement — verified across two real, physically separate hosts.

Open, and honest about its limits

Apache-2.0, entire repository, no dual licensing. This is a complete MVP/control-plane skeleton, not yet a finished multi-tenant security boundary — the jailer, cgroup v2 control, and per-VM network namespaces are implemented; seccomp/AppArmor/SELinux policy, quotas, and audit logging still need adding before exposing it to untrusted tenants. Network Fabric is GA. Secure Containers is developer preview.

Read the full maturity caveat →
CI statusApache 2.0 license

Standalone, or part of the Zyvor platform

FluxVM itself is Apache-2.0 with no commercial tier — adopt it directly with no other Zyvor product required. It's also the VM engine under Zyvor Fabric and Ragnarok, which do offer production support and SLAs, for teams that want the orchestration/UX layer on top.

Contact sales@zyvor.dev