Everyone else ships a hypervisor and a thing to manage it. We ship one binary.
That is not a slogan, it is the architecture. No management appliance. No controller VM on every node. No second product for immutable backup. Here is what that changes, line by line, against the platforms you are probably running today.
Comparisons reflect publicly documented architecture · KVM · libvirt · ZFS · Open vSwitch · Debian 13
Architecture, side by side
| Capability | SynVirt | VMware vSphere | Nutanix AHV | Proxmox VE | Morpheus |
|---|---|---|---|---|---|
| What you deploy before VM #1 | ✓ Nothing. One ISO installs the node and the node is the manager. | A management appliance VM, sized, patched and protected | A controller VM on every node, forever | Nothing extra — but storage and networking are yours to assemble | Its own appliance — and a hypervisor underneath it that you still buy |
| What the platform costs you per node | ✓ One Rust process. API, web UI and TLS in a single binary. | Hypervisor plus a share of the management appliance | RAM and vCPU on every node, taken from the hardware you bought for workloads | A web UI per node — genuinely light | A management layer on top of everything else you already run |
| Licensing | ✓ Per CPU socket. Four tiers. Unlimited VMs on all of them. | Per-core subscription, with a core minimum per CPU | Capacity- and node-based subscription | Free; pay for support and the enterprise repository | Per workload, on top of what you already license |
| Immutable backup | ✓ In the box. S3 Object Lock, verified — the engine checks the lock, it never trusts the claim. | Buy a third-party product | Buy a third-party product | Install and run a second product | Orchestrates someone else's backup |
| Two nodes and a witness | ✓ Twin mode. Synchronous replication, lightweight witness, promoted in place — no reinstall. | Two-node cluster plus a witness appliance | Possible, but the model is built for larger clusters | Needs an external quorum device | Whatever the platform underneath does |
| Getting your VMs out of where they are | ✓ Six live-pull adapters and ten offline formats. Windows guests get virtio drivers injected automatically. | We pull from it | We pull from it | We pull from it | It does not move VMs — it manages the platforms that hold them |
| Running with the internet unplugged | ✓ 100 %. The install never reaches the network and the platform never phones home. | Expects connectivity for licensing and telemetry | Expects connectivity for licensing and telemetry | Runs offline | Requires its own services to be up |
| Mixing hardware in one cluster | ✓ Five roles — HCI, Compute, Storage, Backup, Replica — mixed freely. The GPU box and the disk shelf both get a job. | Compute and storage are separate products, licensed separately | Hyperconverged by design; dedicated roles are a bigger conversation | Nodes are uniform; specialised roles are hand-assembled | Not a node model at all |
| Turning RBAC on without breaking Monday | ✓ Starts in report-only, so you see every would-be denial before enforcing. A pinned super-admin can never be locked out. | Granular and mature — and a project to model | Mature, tied to the management plane | Roles exist; less granular | Governance is the product's whole point |
| When the network is down and you are at the console | ✓ 23 text-mode screens on tty1: network, DNS, NTP, logs, diagnostics to USB, factory reset. | A basic direct console | Host shell and a few utilities | A shell | Nothing — it is not on the host |
Leaving what you have today
From an enterprise virtualization estate
The vim_api adapter pulls VMs live from the incumbent control plane. Full copy, then delta sync, then a cutover window measured in minutes — not a maintenance weekend.
From a hyperconverged appliance
The prism_api adapter reads the existing cluster's inventory and moves workloads onto ZFS, freeing the RAM and cores the controller VMs were consuming.
From an open-source KVM platform
pve_api and libvirt_remote both pull from KVM-based estates. Same kernel hypervisor underneath, so guests land without translation.
From a Windows-based hypervisor
The wmi_api adapter handles the live path and VHDX/VMCX handle the offline one, with virtio drivers injected automatically so Windows guests boot on the first try.
From an older XenServer estate
xen_api for live pulls, XVA for exports. Legacy Windows guests are covered too — the guest agent goes back to XP and Server 2003.
From a pile of disk images
Ten offline formats: OVA, OVF, VMX, VMDK, VHD, VHDX, QCOW2, VDI, VMCX and XVA. Drop in an archive, get a running VM on a ZFS zvol.
One platform, five kinds of host
Most platforms make every node look the same and then sell you a second product when it does not fit. A SynVirt cluster mixes roles freely, so the GPU box, the disk shelf and the old 1U all keep a job.
HCI
Compute and ZFS storage colocated. Dense and simple — the recommended shape for 3 to 8 nodes.
Compute
VMs only, consuming storage from the cluster. The right role for a GPU box or a memory-heavy node.
Storage
Storage only, exposing its pool to the cluster. For I/O-intensive estates that outgrew colocation.
Backup
Dedicated to immutable S3 backups with object lock, isolated so backup I/O windows never touch production VM performance.
Replica
Dedicated to asynchronous DR replication to a remote cluster, on isolated network and storage.
Standalone
One node, local ZFS, no cluster at all. A first server or a lab — promotable to Twin or Cluster without reinstalling.
Comparisons describe publicly documented architecture and licensing models as of July 2026, and are provided to help you evaluate design trade-offs. Vendors change terms; verify anything that matters to your decision. All product names and trademarks belong to their respective owners and are used here for identification only.