Apple container and Virtainer AppVM: the same idea
Apple's container and Virtainer's AppVM reached the same idea on their own: boot a container image as its own virtual machine. Apple built it for the Mac. Virtainer built it for x86_64 servers, where it also runs classic Linux VMs on the same host.
TL;DR — Two separate teams reached the same answer at the same time. The best way to isolate a workload is to give it its own virtual machine, not a slice of a shared kernel. Apple’s
containerdoes this on the Mac. Virtainer’s AppVM does it on x86_64 servers, where it runs next to classic Linux VMs on the same host.
Apple now runs every Linux container inside its own virtual machine. That matters.
We have made the case before that the machine should be the boundary. A real machine wall beats a shared kernel, and that wall is now cheap enough to use everywhere. We reached this view on our own. We were not following anyone. So it stood out to see Apple build the same idea into the Mac at about the same time, with no connection to us.
Apple picked the same path
Apple’s container runs Linux containers on Apple-silicon Macs. Most tools pack many containers onto one shared kernel. Apple does not. It gives each container its own small virtual machine, with its own kernel. Apple’s own docs say why: each container then has “the isolation properties of a full VM,” kept small so the attack surface stays small.
Here is the part that matters. A company that cares deeply about security, and ships to a huge number of users, looked at how to run containers safely. It chose to put each one inside its own machine. So the idea that the machine is the boundary is not a fringe view. Apple reached it on its own. When two unrelated teams build the same thing at the same time, that is a strong sign the idea is right.
Virtainer’s AppVM: the same thing, server-side
Apple built for the desktop. Virtainer built for the server. The part of Virtainer that matches Apple’s container is AppVM.
AppVM does the same job. You give it a container image, and it boots that image as its own virtual machine. The VM has its own kernel and a hardware-enforced boundary on Linux and KVM, and it runs on x86_64 server hardware. No container engine runs inside the guest. The machine is the boundary. The app still gets the controls you expect: auto-restart, resource limits, and health checks. It just gets them with the isolation of a real machine.
The two differ in scope. Apple’s container runs container images, and that is all. Virtainer is a server platform. On a Virtainer host, AppVMs run next to classic Linux VMs booted from standard cloud images. App workloads and full virtual machines run side by side, managed the same way, on the same box. You run it like infrastructure: one web console and an API, with atomic host updates and a clean rollback in a single reboot.
Same idea, two different homes
Apple’s container and Virtainer’s AppVM are not competing. They are the same idea in two different homes. The differences are about where you run and what you run, not which one is better.
| Aspect | Apple container | Virtainer AppVM |
|---|---|---|
| Built for | Apple-silicon Macs (desktop) | x86_64 servers (your own hardware) |
| What it does | Boots a container image as its own VM | Boots a container image as its own VM |
| Isolation | One VM per container, its own kernel | One VM per workload, its own kernel |
| Role | Developer tool: run containers locally | Server platform: isolate app workloads |
| You run it with | A command line on your Mac | A web console and an API on the host |
| Best for | Building and testing images with VM-level isolation on a laptop | Running and isolating app workloads on your own servers |
Virtainer does not stop at AppVM. The same host also runs classic Linux VMs from standard cloud images. App workloads and full virtual machines sit side by side. Apple’s container runs container images only.
Apple put the machine boundary on the developer’s desktop. Virtainer puts it on the server, across the full mix of workloads that real systems run. Same path, two doors.
Learn more about Virtainer at virtainer.io, or get in touch.