Why we bet on MicroVMs for regulated compute

Modern cloud infrastructure inherited its assumptions from enterprise virtualisation. Large, long-lived virtual machines. Broad device emulation. General-purpose operating systems running beneath every workload. These systems were designed for flexibility and compatibility, not for adversarial or highly regulated environments.

That legacy matters.

Traditional virtualisation platforms expose expansive attack surfaces. Emulated devices, legacy drivers, management interfaces, and privileged control paths all increase complexity. Each additional component widens the space in which misconfiguration, vulnerability, or escalation can occur. In regulated environments, this is not an abstract concern. It is a systemic risk.

Containers attempted to address this by reducing overhead and accelerating deployment. But they do so by sharing kernels and relying heavily on policy enforcement for isolation. Namespaces, cgroups, and admission controls are powerful, but they remain logical constructs layered atop a shared execution substrate.

When isolation fails in these systems, it fails completely.

The regulatory reality

For sovereign and regulated workloads, this model is insufficient. Compliance frameworks do not merely ask who can access a system. They increasingly ask what is structurally possible within it. They care about containment, blast radius, and failure modes. They assume that misconfiguration and compromise are not hypothetical, but inevitable.

MicroVMs are the response to this reality.

A MicroVM deliberately strips virtualisation down to its irreducible core. A minimal kernel. A constrained device model. A sharply defined interface to the host enforced by hardware virtualisation. Everything else is removed—not hidden behind configuration.

This reduction is not about efficiency alone. It is about trust boundaries.

Isolation by construction

Each MicroVM executes as a self-contained unit with its own kernel, memory space, and CPU context. There is no shared kernel. No ambient privilege. No implicit lateral movement. The system enforces isolation by construction, not by convention.

Just as importantly, MicroVMs are designed to be ephemeral. They are created, executed, and destroyed with minimal retained state. This changes the operational posture of infrastructure entirely. Compromise does not persist. Drift does not accumulate. Recovery becomes mechanical rather than investigative.

For regulated compute, this matters more than raw performance.

Why Firecracker

This is why we view MicroVMs not as an optimisation, but as a foundational primitive.

They align naturally with jurisdictions that require strong isolation, explicit control, and demonstrable guarantees. They support architectures where sovereignty is enforced at the workload level, not assumed at the platform level. They allow compute to be treated as a series of constrained, inspectable execution cells rather than a shared pool governed by intent.

Firecracker exemplifies this philosophy. It does not attempt to be everything. It does not optimise for legacy compatibility. It optimises for minimalism, isolation, and determinism. In doing so, it offers something rare in modern infrastructure: a system whose security properties improve as it becomes simpler.

The IsoCell foundation

We bet on MicroVMs because regulation rewards clarity over convenience. Because isolation must be enforced by hardware, not hoped for through policy. And because in environments where trust is scarce, reducing what the system can do is often more important than expanding what it might do.

This is the foundation on which we built IsoCell.

“A system whose security properties improve as it becomes simpler.”