Cross-host live migration
Capture a running FlashVM, move the file, restore it on a different host. Verified between independent physical machines running different kernel versions.
How migration works →Standalone hypervisor for instant, isolated VMs
Instant, not just fast.
We built a hypervisor named FlashVMM that boots our own microVM, FlashVM, in single-digit to low-hundred milliseconds depending on architecture, then snapshots it, restores it, or moves it live to a different physical host mid-workload. A pool of spares sits already-running, so most of the time "start" isn't a boot at all — it's a claim. One binary, one process per VM, no daemon, no cloud dependency to run it. The same CLI a human types, flash-mcp exposes whole to an AI agent, so a fleet can be driven by either.
4.58 ms
cold boot
1.36 ms
warm / snapshot restore
Live migration
move a running VM to a different physical host
Warm-pool replicas
claimed, not booted — bare metal or nested virt, at fleet scale
Nested virt
KVM inside KVM — snapshot and restore included
Live memory resize
virtio-mem grows or shrinks a VM's RAM on demand, no reboot
10 MCP tools
full fleet control for AI agents
5 independent caps
CPU, memory, disk capacity, disk I/O, network — per VM
Live streaming
metrics, logs, and events over SSE
Capabilities dropped
per-thread seccomp, before guest code runs
~29x faster
cold boot vs. Firecracker
Methodology and raw data for every number: Performance.
The architecture behind the numbers
Speed isn't just a fast cold boot.
Live migration, warm-pool claim, and an AI-native control plane are the same architecture the marquee numbers above come from — not separate features bolted on afterward.
Warm-pool claim
A pool of spares sits already-running. Starting a workload means claiming one — no kernel load, no device init.
See the architecture →AI-native control plane
flash-mcp: a 10-tool Model Context Protocol server that runs seamlessly on x86_64 and ARM.
flash-mcp →How we make claims
Independent, on purpose.
FlashVMM has zero dependency on any other product's repository, signing keys, CDN, or updater. One install, works standalone — that's a design principle, not an accident of scope.
Mechanisms over adjectives
Every claim on this site maps to a named mechanism, a real measurement, or a disclosed limitation — never an unverifiable superlative. If a number is on this site, its methodology and raw data are published alongside it.
Disclosed limitations, not buried ones
Where a Performance measurement favors Firecracker, that's published too — see the Raspberry Pi 5 GICv2 restore number on the Migration page.
Under the hood
Security, performance, independence.
Capability drop and per-thread seccomp on every VM. A published benchmark against Firecracker, methodology and raw data included. Zero dependency on any other product's repo, keys, CDN, or updater.
Capability drop, per-thread seccomp
Every FlashVM process drops capabilities before guest code runs, hardened with a per-thread seccomp allowlist.
The isolation model →Benchmarked against Firecracker
Four environments — local bare metal, AWS Graviton3, AWS nested virt.
Read the comparison →Standalone
Not a component of a larger platform. Doesn't reach into another project's repo, doesn't share signing keys with anything else, doesn't require a specific CDN, doesn't depend on another product's update mechanism. If you install FlashVMM, that installation is complete.
Why not just give it a try.
No accounts, no dashboard — just a CLI and a hypervisor.