# How we isolate customer workloads with Kata micro-VMs > The difference between a namespace and a hypervisor as a security boundary, what it costs in memory and boot time, and why it matters more now that a model wrote the code. The difference between a namespace and a hypervisor as a security boundary, what it costs in memory and boot time, and why it matters more now that a model wrote the code. 18 Mar 2026 · 4 min read · cmdz Most platforms in this category run customer code in containers sharing one kernel. We run every workload in a virtual machine with its own kernel. This post is about what that difference is actually worth and what it costs. ## What a container boundary is A container is a process with a restricted view: namespaces limit what it can see, cgroups limit what it can consume, seccomp limits which system calls it may make. It is a good boundary. It is also, fundamentally, **one kernel**. Every container on the node calls into the same kernel, and the security of the whole arrangement rests on that kernel having no exploitable bug reachable from the syscall surface you left open. Kernels have such bugs. Not often, and they get patched, but "not often" is a different claim from "not at all" and the difference is what a security model is made of. ## What a micro-VM boundary is A Kata Containers workload runs inside a lightweight virtual machine. Your process calls into **its own** kernel, running in its own virtual machine, on virtualised hardware. To reach the host, an attacker needs a hypervisor escape rather than a kernel escape. Those are dramatically rarer, dramatically harder, and the attack surface is dramatically smaller — a hypervisor exposes device emulation, not three hundred system calls. From Kubernetes' point of view it is still a pod. Same scheduling, same networking, same lifecycle. It is a runtime class, not a parallel universe. ## What it costs Honesty about the trade: **Memory overhead**, roughly 40–60 MB per workload for the guest kernel and the VM. On a 1 GB app that is about 5%. **Boot time**, about 90 ms versus about 20 ms for a plain container. Relevant only on a cold start, and dwarfed by your own process start unless your app boots in under 100 ms. **Slightly slower I/O**, in the low single-digit percent for typical application workloads through virtio. For a database doing heavy sequential I/O the overhead is more noticeable, which is why our managed databases are tuned for it specifically rather than treated as one more workload. Overall: a few percent of resources and a few tens of milliseconds, for a categorically different security boundary. We think that is an easy trade and we would make it even if nobody asked. ## Why it matters more now Here is the part that changed. A growing share of the code running on platforms like this one was written by a language model and reviewed by a person under time pressure — sometimes not reviewed at all. That code pulls dependencies chosen by the same model. Some of those dependencies are typosquats. Some of them are fine today. This is not an argument that AI-written code is bad. It is an observation that the **volume** of code being deployed by people who have not read every line has gone up by an order of magnitude in two years, and that a shared-kernel boundary was designed for a world with a different ratio. If the code in the container might do something its author did not intend, you want the boundary under it to be the strongest one available at reasonable cost. ## What it does not protect against A security section that only lists strengths is marketing. **It does not protect you from your own application's bugs.** SQL injection in your app reaches your database, which is inside your boundary. Isolation protects other customers from you and you from them; it does nothing about you and yourself. **It does not protect against a supply chain attack in your dependencies.** A malicious package running with your app's credentials has your app's credentials. That is a real risk and the mitigation is different — pin your dependencies, review the diff, keep secrets out of the client bundle. **It does not make us invulnerable.** A hypervisor escape is rarer, not impossible. We patch, we monitor, and we would tell you if it happened. ## The rest of the stack Isolation is one layer of several: **Network segmentation per project.** A workload reaches its own services and the internet. There is no flat internal network, so no connection string reaches another customer's database however it is constructed. **Encryption at rest.** Full-disk encryption on every node, with keys released by a network-bound service at boot rather than stored on the machine. A disk that leaves the rack is unreadable. **Least privilege in the control plane.** The reconciler that writes to the cluster cannot read your secrets. The API that reads your secrets cannot write to the cluster. **Audit everything.** Every state change writes an append-only line with an actor and a request id. ## Who else does this Fly.io, with Firecracker. Same category of boundary, different hypervisor, and their global placement is better than ours. We mention them because a security claim you present as exclusive when it is not is the fastest way to lose the reader who knows the field. Our isolation is not a differentiator on its own. The combination — this isolation, a hard spending ceiling, and a full write API for agents — is. ## Verifying it ```bash cmdz shell web uname -a ``` The kernel version you see is your workload's kernel, not the node's. You can check what the node runs on the status page; they will differ. That is a small thing, but it is the difference between believing a security claim and confirming one. ## Set your limit and start. One click with a passkey, then you verify a payment method once to start your 14-day free trial (€ 10 of credit). After that it is prepaid pay-as-you-go — you only ever spend credit you have already bought, and no invoice ever arrives above the amount you set. - [Create account](https://app.cmdz.com/signup) - [Read the docs](https://docs.cmdz.com)