Why I built my cloud platform on micro-VMs instead of containers (a security story)

Dhruv malaviya — Wed, 03 Jun 2026 07:55:21 +0000

Containers are great until you remember they all share one kernel. For a lot of workloads that's fine. But the moment you're running untrusted code, multi-tenant jobs, or anything you wouldn't want leaking into its neighbours, a single kernel exploit is the whole game. That worry is exactly why I made an early architecture call for my platform, Krova krova: no shared-kernel containers.

Enter Firecracker
Firecracker is the open-source micro-VM monitor AWS built to run Lambda and Fargate. Each instance is a real hardware-virtualized VM (KVM under the hood) with its own kernel, but it boots in around 125ms and carries almost none of the weight of a traditional VM. You get the isolation boundary of a VM with something close to the start-up feel of a container.

That trade-off is perfect for security-minded, ephemeral work:

Hypervisor-level isolation. Tenants are separated at the virtualization boundary, not by namespaces over a shared kernel.
Tiny attack surface. Firecracker deliberately ships a minimal device model, far less exposed than a full VM stack.

How Krova uses it

Every machine on Krova (a "Cube") is its own Firecracker micro-VM with its own kernel. They get private internal networking rather than a public IP each, ingress is explicit port mapping, and you can sleep or destroy a Cube the instant you're done. So "run something untrusted, then make it vanish" is the default path, not a thing you bolt on.

And because they boot in about a second and keep their disk between sleeps, the security model doesn't cost you convenience, which is usually the part that makes people skip isolation in the first place.

DEV Community: Dhruv malaviya

Why I built my cloud platform on micro-VMs instead of containers (a security story)