VM-per-container explained

There’s a common mental model when it comes to running containers: a single virtual machine (VM), hosting a full Linux OS, running containerd or Docker and managing multiple containers side by side. This is how tools like Docker Desktop, Colima, Lima, and Rancher Desktop work today.

But that’s not the only model—and it’s not the most secure.

With the introduction of Apple’s Container Framework (and the architectural direction we’ve taken at Edera), a new model is becoming more visible: a dedicated VM per container. It sounds heavier—but it isn’t. In fact, it’s more secure, easier to isolate, and opens the door for performance and management gains that the traditional shared-VM model can’t match.

This guide walks through the differences, clarifies common misconceptions, and explains why Edera chose the per-container VM model for production infrastructure.

---

Traditional model: one VM, many containers

In Docker-based systems like Docker Desktop, a single Linux VM is created (usually via hyperkit or QEMU). That VM runs containerd or dockerd, which orchestrates and executes all containers in a shared kernel and user space.

• All containers share the same kernel
• A container escape = visibility into the whole node
• Secrets, /proc, memory, and process tables are shared
• Proxying Docker sockets and mounting volumes is straightforward

This works well for development — but it’s risky in production.

---

Apple Container Framework: a VM per container

Apple flips the model: each container runs inside its own lightweight VM.

• The VM boots a minimal Linux kernel
• Inside is just a container and a tiny init (Apple: vminitd, Edera: Rust init)
• No systemd. No daemons. No bloat.
• Hypervisor isolation — not just namespace separation

Despite how it sounds, this is:

• Fast to boot
• Highly isolated
• Far more secure than the shared-kernel model

---

What Edera adds (beyond Apple)

Edera brings this architecture into production, adding:

• 🔍 Observability and lifecycle tooling
• 📦 Kernels and drivers shipped as OCI images
• 🌐 No KVM or nested virtualization — we use a paravirtualized hypervisor

That last point means:

• No dependency on vmx or special hardware
• Runs anywhere: cloud, local, edge, dev machines

---

Demo: Docker vs Apple Container Framework

In this demo:

• One container sets an environment variable containing a secret
• The other container tries to read it

Result:

• In Docker: the secret is visible via /proc
• In Apple’s container model: the second container is in its own VM — it can’t see anything

---

What changes with micro-VMs?

Feature	Docker / Colima / Lima	Apple Container	Edera
Kernel per container	Shared	Isolated	Isolated
Nested virtualization needed	Yes	No	No
Full distro inside VM	Often	Minimal	Minimal
Observability + mgmt	Limited	Limited	Built-in
Security boundary	Namespace	Hypervisor	Hypervisor

When you run a VM per container, you’re not just isolating workloads—you’re redefining the threat model.
This is where containerization is headed. Edera’s already there.
To learn more check out our architecture overview.