apache 2.0macos + linuxgithub.com/tinylabscom/mvm
Run code you don’t trust.
Agent execution a security team can approve.
Hardened microVMs under a signed execution contract. Sub-150 ms boot. Configurable to the kernel.
macOS 13+ (libkrun on 13–25, HVF on 26+) or Linux with /dev/kvm.
code is getting cheaper to write. so are exploits.
generated
Agents ship code faster than any review cycle.
unreviewed
Hallucinated packages and unvetted deps ride along.
exploitable
A prompt-injected agent with network access is an exfiltration path.
With MVM Security first isn’t a tier, it’s the default.
The contract
the box is table stakes. the contract is the product.
Anyone can put an agent in a microVM. A security team approves the contract: what may execute, with what authority, and what proves it. Six layers, enforced and witnessed — not asserted.
01
Signed admission
Nothing boots without a signed, audited ExecutionPlan — validity window, nonce, chain-signed lifecycle.
claim 8
02
Pinned artifact
Artifacts are content-addressed and digest-pinned, re-verified at fetch and again at admit.
claims 9, 14
03
Granted authority
Network, services, and credentials are grants in the plan — deny-all by default, raw secrets never in the guest.
claims 10, 12, 13
04
No bypass path
The guest has no network device. Every byte exits over one vsock channel the host can refuse.
claim 10
05
Sealed, immutable production behavior
A dm-verity-sealed rootfs with no shell, no PTY, no dev verbs — the admitted program can't be swapped.
claims 3, 15
06
Verifiable record
Every admission and policy decision lands in a chain-signed audit log. Tampering breaks the chain.
claims 8, 14
Quickstart
file in.
running microVM out.
mvmctl reads the decorator statically, builds a rootfs inside a builder VM, and boots the workload in its own kernel — nothing you run here ever executes on your host.
Read the full quickstart guide1@mvm.app(2 image=mvm.python_image(python="3.12"),3 resources=mvm.resources(cpu=1, memory_mb=256),4 env={"NAME": "danny"},5 before_start="export FOO=1",6)7def main() -> None:8 print(f"hello {os.environ['NAME']}")The boundary
Why A MicroVM
Every mvm workload boots its own guest kernel under a real hypervisor, on its own root filesystem — a hardware-assisted boundary, not a shared one.
- its own Linux kernel — booted fresh, under a real hypervisor
- its own root filesystem — not a view onto the host's
- no network device — on any backend — HVF, libkrun, Firecracker
- one channel out — vsock, deny-all until policy admits it
Performance
measured, not asserted.
The dispatch window — an admitted execution plan to the guest command running. The arc is the budget CI enforces on every launch; the fill is what one named host actually did, revalidated sample by sample before it was allowed onto the page.
p50
86% of ceiling171.5ms
ceiling 200 ms
p95
70% of ceiling176.0ms
ceiling 250 ms
p99
59% of ceiling178.0ms
ceiling 300 ms
- lane
- prepared_cold
- backend
- Firecracker v1.14.1
- host
- Linux 6.8.0-137 x86_64, Intel i7-7700
- storage
- rotational md-RAID (ROTA=1)
- samples
- 20 (+2 warm-ups)
- date
- 2026-08-19
Measured on spinning media, where a large fixed fraction of the window is fsync cost that disappears on NVMe — so this is a pessimistic reading, not a favourable one. Budgets, disqualification rules, and the raw report digest are on the launch performance page.
Deployment
one contract. four places to run it.
01 / Local
Local Development
libkrun/HVF-backed VMs on your macOS or Linux machine. Same workload contract.
02 / Hosted
Design partnersHosted Standard
Firecracker on Linux/KVM fleet infrastructure. High-density, short-lived workloads.
03 / Edge
RoadmapEdge & Private
Your VPC or your metal. The same signed contract, forward-deployed into your infrastructure.
04 / Confidential
RoadmapHosted Confidential
AMD SEV-SNP and Intel TDX. Hardware attestation is out of scope of today's shipped runtime.
Local runs today with the open-source CLI. Tier status is tracked on the capability status page; what’s enforced right now — with named test witnesses — is in the CI-enforced claims.
Backends
the backend is an implementation detail.
The same signed image, decorated execution plan, policy bundle, and audit chain runs across every backend MVM supports.
Linux / KVM
Firecracker
macOS 13–25
libkrun
macOS 26+
HVF
Dev / test
QEMU
Shipped, preview, and roadmap capabilities are tracked on the capability status page.
Questions worth asking
faq
Why not just use a container?
A container is namespaces and cgroups around processes that still call straight into the host kernel — one kernel, shared by everything on the box. Every mvm workload boots its own Linux kernel under a real hypervisor, with no guest network device on any backend. The isolation is hardware-assisted, not namespace-assisted.
Which languages are supported?
The CLI (mvmctl) drives any workload from a shell. The decorator SDK, for declaring workloads in source, is available for Python and TypeScript. The runtime SDK, for driving a sandbox imperatively, is partial in Python and TypeScript today; a Rust lifecycle client is planned, not shipped.
Is it open source?
Yes — Apache-2.0, source at github.com/tinylabscom/mvm.
What does it run on?
macOS 13–25 on libkrun, macOS 26+ Apple Silicon on the in-house HVF backend, and Linux with /dev/kvm on Firecracker. mvmctl reads your OS, chip, and macOS version and picks one for you.
What is the security posture?
Fifteen-plus numbered claims, each backed by a named test or CI job — not adjectives in a doc. The host itself is trusted; a malicious host, mutually distrusting guests in one VM, and hardware key attestation are explicitly out of scope.
Request access
run the workload. isolate the tenant. enforce the policy. audit the execution.
Working with a small group of design partners building agent platforms, code interpreters, secure workflow runners, multi-tenant SaaS, and edge AI workloads.
run something you don’t trust.
One install command. No daemon, no SSH, and no network until policy admits it.