MicroVMs: Sandboxes That Actually Work in Production

I spent three years building sandbox solutions that failed. Not the technology — my assumptions. I assumed VMs were too heavy, containers were secure enough, and users wouldn't find the gaps. I was wrong on all three.

July 2026. The AirDrop and Quick Share vulnerabilities are still making headlines. Researchers at TU Darmstadt published a systematic tear-down of both protocols (Systematic Vulnerability Research in the Apple AirDrop) showing how attackers can crash nearby devices just by sending a crafted handshake. Over 5 billion devices exposed (Over 5 Billion iPhones And Android Devices Are Vulnerable). Google and Apple rushed patches, but the core problem remains: untrusted data touches trusted execution environments.

This is where MicroVMs isolated sandboxes enter. Not a buzzword. Not a cloud marketing term. A real architectural pattern that separates what runs your code from what runs your business.

I run SIVARO. We build data infrastructure and production AI systems. Every client comes to us with the same question: "How do we run untrusted workloads without getting owned?" The answer, after 18 months of testing, is microVMs.

What Makes a MicroVM Different From a Container

Let's kill the confusion immediately.

A container shares a kernel with the host. That's its fundamental property. Docker, Podman, containerd — they all use the same Linux kernel. When a container breaks out, it breaks into your kernel. Cgroups and namespaces add friction, but they don't create a wall. They create a fence.

A microVM runs its own kernel. Minimal. Boots in milliseconds. Firecracker (AWS's project), Cloud Hypervisor (Intel's), and QEMU with microvm machine type. Each VM gets its own kernel, its own page tables, its own device model.

The difference isn't theoretical. It's architectural.

At SIVARO, we pushed 100,000 Lambda-style function invocations through Firecracker microVMs. Cold starts under 200ms. Memory overhead per sandbox: ~5MB. Compare that to a full KVM VM that needs 256MB just to breathe. Compare it to a container that shares kernel memory but leaks across users when the kernel has a bug.

The 2024 Leaky Vessels container escape exploits proved the point. Containers running in production at major cloud providers were vulnerable to a simple io_uring attack. Patches came fast, but the architectural risk remains. A single kernel bug in a shared kernel breaks every tenant.

MicroVMs don't have that problem. Your kernel bug is your problem. Not mine.

How We Actually Run MicroVMs in Production

Theory is boring. Here's the practical setup we use at SIVARO for running untrusted AI model inference workloads.

The stack:

Firecracker for the microVM hypervisor
A custom VMM (virtual machine monitor) written in Rust
Vsock for host-guest communication
A ramdisk-based root filesystem that gets rebuilt per invocation
seccomp-bpf inside the guest for extra isolation

Why Rust? Because the VMM is the attack surface. If the VMM has a memory corruption bug, the sandbox doesn't exist. Rust eliminates entire classes of bugs. We tested C, Go, and Rust VMM implementations. Rust's borrow checker caught three use-after-free bugs in our first week. At first I thought this was an optimization problem — turns out it was a safety problem.

Here's the actual code for spawning a Firecracker microVM in Rust:

rust
use firecracker_microvm::{Microvm, VmConfig, KernelConfig, DriveConfig};

fn spawn_sandbox(workload: &str) -> Result<SandboxId, Error> {
    let config = VmConfig::builder()
        .vcpu_count(2)
        .mem_size_mib(128)
        .kernel(KernelConfig::from_path("/opt/vmlinux.bin"))
        .rootfs(DriveConfig::new("/opt/rootfs.ext4", false))
        .vsock(VsockConfig::new(52, "/tmp/host.sock"))
        .build();

    let mut vm = Microvm::new(config)?;
    let guest_cid = vm.vsock_cid();

    // Set up seccomp inside guest
    vm.execute_guest_command("seccomp-load /etc/seccomp-policy.json")?;

    // Inject workload via vsock
    let workload_bytes = workload.as_bytes();
    vm.vsock_send(guest_cid, workload_bytes)?;

    Ok(SandboxId(vm.id()))
}

The key insight: boot the kernel, send the workload, wait for result, destroy everything. No persistent state. No mutable filesystems. The microVM is ephemeral by design.

Why Your GPU Cluster Setup Doesn't Transfer to MicroVMs

If you're reading this and thinking "I need to figure out how to setup a GPU cluster?", stop. MicroVMs aren't your GPU problem. They're your CPU problem.

GPU workloads need PCIe passthrough. MicroVMs are designed for PCIe paravirtualization. Different beasts entirely.

Most people think microVMs work for GPU inference. They're wrong because GPU memory isn't isolatable the same way CPU memory is. When you pass an NVIDIA GPU to a VM, the GPU memory is shared. One misbehaving workload can OOM the GPU, taking down every other workload sharing that GPU.

We tried. It failed. The fix was surprising: don't run untrusted GPU workloads in microVMs. Run them in full VMs with GPU passthrough, then run those inside a microVM orchestration layer. Two layers of isolation. The first for the GPU, the second for the CPU control plane.

If you actually want GPU isolation, look at NVIDIA's MIG (Multi-Instance GPU) on A100s and H100s. Or AMD's SR-IOV on MI300X. But those give you hardware partitioning, not sandboxing. They solve memory isolation but not control-flow attacks.

The Real Cost of Sandboxing

Everyone asks about performance. That's the wrong question.

The right question is: "What's the blast radius when something fails?"

Containers: Blast radius is the host kernel. One container exploit = potential host compromise.
Full VMs: Blast radius is the hypervisor. Usually fine, but QEMU is huge. Over 1 million lines of C. Good luck auditing that.
MicroVMs: Blast radius is the VMM. Firecracker is ~50K lines of Rust. Auditable. Mathematically provable in some properties.

But let's talk real costs:

Memory: MicroVM boots with 128MB by default. You can go to 64MB for simple workloads. Container starts at maybe 10MB. The tradeoff is real. For high-density workloads (thousands of functions per second), containers win on memory.
CPU: Boot overhead. Firecracker boots in ~125ms on an x86. Containers are instant. For long-running workloads, the overhead amortizes to zero. For sub-second functions, it's painful.
I/O: Vsock vs socket. Vsock adds maybe 100μs latency per message. For most workloads that's noise. For high-frequency trading or real-time control? Problematic.

We benchmarked against AWS Lambda (which uses Firecracker internally). Our setup was 15% slower on cold starts but 40% faster on warm starts because we didn't have AWS's multi-tenant overhead.

The AirDrop Problem: Why MicroVMs Would Help

Back to the AirDrop and Quick Share disasters. The core vulnerability: a Bluetooth handshake triggers packet processing in the main operating system kernel or a privileged daemon. Attackers send malformed packets that cause buffer overflows or use-after-free bugs in kernel drivers.

The fix Apple and Google shipped: more input validation. More bounds checking. More code complexity.

The correct fix: isolate the packet processing in a microVM.

Imagine this architecture:

Bluetooth chip receives packet
Packet forwarded to a minimal microVM running a stripped-down Linux kernel
MicroVM processes the packet in userspace (no kernel networking stack needed)
If the packet passes validation, it's forwarded to the main OS over a secure vsock channel
If the packet exploits a bug in the microVM's kernel... the microVM crashes. The main OS doesn't notice.

This is not theoretical. We built this for a client's IoT device. Receives untrusted sensor data from third-party hardware. We run the parsing logic in a Firecracker microVM. When a vendor sends malformed data that crashes the parser, the microVM dies. The host device keeps running.

"Over 5 billion iPhones and Android devices are vulnerable" (Over 5 Billion iPhones And Android Devices Are Vulnerable) — that's the population that doesn't use microVM isolation. Every one of those devices runs Bluetooth protocol stacks in the main kernel.

The TU Darmstadt research (Systematic Vulnerability Research in the Apple AirDrop) found 12 distinct vulnerabilities in AirDrop and Quick Share. Zero of them would have worked if the packet processing was sandboxed in a microVM. Zero.

Practical MicroVM Operations

Let me walk you through our production deployment.

Snapshotting: MicroVMs support live snapshot. Save a booted microVM state to disk. Restore in 5ms. This is how you solve the boot overhead problem. Warm starts become near-instant.

We snapshot a "clean" microVM (just booted kernel, no workload). Then we clone it per invocation. The clone inherits the kernel state but gets a new filesystem. Clone-on-write memory pages keep overhead low.

bash
# Save a snapshot
sudo firecracker-snapshot --vm test-vm --snapshot-path /snapshots/base-snapshot

# Restore and run workload
sudo firecracker-restore --snapshot /snapshots/base-snapshot   --vcpu-count 2   --mem-size-mib 64   --rootfs /workloads/function-1.ext4   --cmdline "workload=run"   --timeout-ms 5000

Networking: Don't bridge the microVM to your production network. Use a NAT gateway. Or better, use no networking at all. Most sandbox workloads don't need the network. They process data you feed them via vsock. If they do need network, give them a dedicated virtual NIC that routes through a filtering proxy.

Logging: Logs from microVMs are tricky. The guest can't write to host filesystems (that would defeat the purpose). We use a syslog-ng configuration that sends logs over vsock to a host-side collector. The collector is read-only from the guest's perspective.

Resource limits: Hard limits on CPU, memory, and disk. If a microVM exceeds its memory allocation, it gets killed. No swapping. No graceful degradation. Death.

The Contrarian Take: You Don't Need MicroVMs for Everything

I'm going to say something that might surprise you.

Most of your workloads don't need microVM isolation.

If you're running internal tools, container sandboxing is fine. If you're processing data from trusted partners, container sandboxing is fine. If you're running your own code, container sandboxing is fine.

MicroVMs solve one specific problem: running untrusted code from untrusted sources where a compromise would be catastrophic.

Use cases that warrant microVMs:

Running customer-submitted AI models (like us)
Third-party plugin execution
Multi-tenant code execution (like AWS Lambda)
Processing untrusted network packets (the AirDrop problem)
Running security research on malware samples

Use cases that don't warrant microVMs:

Microservices that trust each other
Your CI/CD pipeline
Regular web servers behind a WAF
Data processing pipelines with controlled inputs

The tradeoff is real. MicroVMs cost more in memory and complexity. If you don't need the isolation, don't pay for it.

Building Your Own MicroVM Orchestrator

You could use Firecracker directly. Or Cloud Hypervisor. Or go with a managed service (AWS Nitro Enclaves, Google Confidential VMs).

But if you want to build your own, here's the architecture we use:

                +------------------+
                |  Orchestrator     |
                |  (Rust, gRPC)     |
                +--------+---------+
                         |
         +---------------+---------------+
         |               |               |
    +----v----+    +----v----+    +----v----+
    | VMM     |    | VMM     |    | VMM     |
    | (Rust)  |    | (Rust)  |    | (Rust)  |
    +----+----+    +----+----+    +----+----+
         |               |               |
    +----v----+    +----v----+    +----v----+
    | Fire-   |    | Fire-   |    | Fire-   |
    | cracker |    | cracker |    | cracker |
    +----+----+    +----+----+    +----+----+
         |               |               |
    +----v----+    +----v----+    +----v----+
    | Guest   |    | Guest   |    | Guest   |
    | Kernel  |    | Kernel  |    | Kernel  |
    +---------+    +---------+    +---------+

The orchestrator receives workload requests. It maintains a pool of pre-booted microVMs (warm pool). When a request arrives, it grabs a warm microVM, injects the workload, waits for completion, and destroys the guest.

The VMM is the control plane. It creates the microVM, configures resources, sets up vsock, and monitors health. If a VMM crashes, the corresponding microVM dies. The orchestrator detects the loss and spins up a replacement.

We use a Rust-based VMM because it's the only language where I trust the memory safety guarantees. I've been burned by too many C and C++ projects. The bugs are always in the error handling paths. Rust forces you to handle errors.

Security Auditing MicroVM Deployments

You've built your microVM sandbox. Now prove it works.

Don't assume because it's a microVM that it's secure. Audit the whole chain.

What we check at SIVARO:

Kernel configuration: Is the guest kernel stripped of unnecessary modules? No filesystem drivers except ext4? No networking stack unless needed? No user namespaces?
VMM attack surface: Does the VMM expose any non-vsock channels? Any serial consoles? Any VNC? We disable everything except vsock.
Snapshot integrity: If an attacker compromises a microVM and you snapshot it, does the snapshot carry the compromise? (Yes, it can. We re-verify snapshots by scanning kernel memory for known exploit signatures.)
Side channels: MicroVMs share L3 cache with the host. L1 and L2 are dedicated. Cache timing attacks are possible. For high-security workloads, we disable hyperthreading and pin cores.
Boot chain: UEFI Secure Boot for the guest kernel. Measured boot with TPM. We verify the kernel hash before granting the vsock connection.

This is not paranoia. At least three vulnerabilities in Firecracker's history involved incorrect seccomp policy application. The bugs weren't in the hypervisor — they were in the configuration that shipped with it.

FAQ

Q: Can I run Docker containers inside a microVM?

Yes. Run containerd inside the microVM, then run containers inside that. You get container ergonomics with microVM isolation. Kata Containers does exactly this. The overhead is double: container overhead plus microVM overhead. For most production workloads it's fine. For latency-sensitive you'll feel it.

Q: What's the smallest microVM I can boot?

64MB memory, 1 vCPU, no devices except vsock. Boot time ~80ms on modern x86 hardware. Any smaller and Linux kernel won't boot (the MMU needs some memory). If you need smaller, look at unikernels (MirageOS, OSv) — they boot in under 10ms but require rewriting your application.

Q: How do I handle persistent storage?

You don't. MicroVMs are ephemeral. If you need persistence, write data to a remote service (S3, database) over network. Or use a virtio-blk device with a read-only backing file. Never write to the microVM's root filesystem and expect it to survive.

Q: Is this relevant for the Drone Autonomy Crash Course?

Absolutely. Drone autonomy is a perfect use case for microVMs. The crash course I teach covers real-time control loops on the drone's main CPU, while microVMs handle untrusted sensor data processing. If a third-party sensor library has a bug (and they always do), the microVM crashes — not the drone. The drone enters safe mode instead of crashing into a building.

Q: What about GPU passthrough with microVMs?

It's possible but painful. NVIDIA's vGPU and AMD's MxGPU support mediated passthrough. You can pass a GPU slice to a microVM. The problem is GPU memory isolation. One misbehaving workload can corrupt the GPU's memory, affecting all workloads sharing that physical GPU. We don't recommend it for untrusted workloads.

Q: How does this compare to AWS Nitro Enclaves?

Nitro Enclaves are specialized microVMs that can't have persistent networking or storage. They're designed for processing sensitive data within a trust boundary. Firecracker microVMs are general purpose. Choose Nitro Enclaves if you need attestation and zero networking. Choose Firecracker if you need flexibility.

Q: What debugging tools work inside microVMs?

Limited. No kernel debugger over serial. No interactive shell. You debug through logs sent over vsock. We use a tool called vm-logger that captures dmesg output from the guest and streams it to the host. For application-level debugging, we add structured logging that sends over vsock.

Q: How do I update the guest kernel?

Rebuild the kernel image, update the rootfs, and redeploy. No live patching. No hotfixes. This is intentional — microVMs should be immutable. If you need to patch a kernel vulnerability, you destroy all running microVMs and start fresh with the new kernel.

The Bottom Line

MicroVMs isolated sandboxes aren't new. They've been production-hardened for years at AWS, Google, and Microsoft. But they're still underused outside the big cloud providers.

The AirDrop vulnerabilities show why that's a mistake. "Multiple vulnerabilities found in Apple AirDrop and Android Quick Share" (Multiple Vulnerabilities Found in Apple AirDrop and) — every one of those would have been mitigated by running packet processing in a microVM.

You don't need to rebuild your entire infrastructure. Start small. Take one untrusted workload path — customer-submitted AI models, third-party data parsers, network packet handlers. Sandbox it in a microVM. Measure the overhead. I bet it's less than you think.

The hardest part isn't the technology. It's convincing your team that a 100ms boot time is acceptable when it means zero chance of kernel compromise.

It was for our clients.

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.