[{"data":1,"prerenderedAt":362},["ShallowReactive",2],{"switcher-blog-pareja":3,"art-apple-container-vs-docker-linux-en":6},{"en":4,"es":5},"\u002Fen\u002Fblog\u002Fapple-container-vs-docker-linux\u002F","\u002Fes\u002Fblog\u002Fapple-container-vs-docker-linux\u002F",{"id":7,"title":8,"author":9,"body":10,"date":346,"description":347,"extension":348,"image":349,"meta":350,"navigation":351,"pareja":352,"path":353,"seo":354,"stem":355,"tags":356,"__hash__":361},"blogEn\u002Fen\u002Fblog\u002Fapple-container-vs-docker-linux.md","Apple container 1.0: why containers on a Mac will always be a workaround (and how Apple is hiding the seams)","Paco Cubel",{"type":11,"value":12,"toc":328},"minimark",[13,18,35,42,46,62,65,76,79,121,125,136,147,158,165,169,174,181,185,192,196,199,203,206,210,217,224,227,231,255,259,269,279,285,289],[14,15,17],"h2",{"id":16},"what-happened","What happened",[19,20,21,22,30,31,34],"p",{},"On 9 June 2026 — exactly one year after announcing it at WWDC 2025 — Apple shipped ",[23,24,25,26],"strong",{},"version 1.0 of ",[27,28,29],"code",{},"container",", its open source tool for running Linux containers on macOS. It comes with the ",[23,32,33],{},"Containerization"," framework, written in Swift, and it speaks standard OCI images: you can pull from Docker Hub or any registry you already use.",[19,36,37,38,41],{},"The headline doing the rounds is the usual one: \"Apple kills Docker\". It doesn't. What Apple has built is genuinely interesting, but to see what it actually delivers — and what's marketing — you first need to internalise something that plenty of daily Docker users never quite have: ",[23,39,40],{},"a container is not Docker technology, it's a Linux kernel feature",".",[14,43,45],{"id":44},"containers-are-only-native-on-linux","Containers are only native on Linux",[19,47,48,49,53,54,57,58,61],{},"On Linux, a container is an ordinary process on your machine that the kernel fits with blinkers: ",[50,51,52],"em",{},"namespaces"," so it can't see other processes or the host's network, ",[50,55,56],{},"cgroups"," to cap its CPU and memory, and a layered filesystem. No virtualisation, no middle layer, no translation. Run ",[27,59,60],{},"ps aux"," on the host and your containers' processes show up like any others.",[19,63,64],{},"That's why Docker on Linux just works, and why it's what runs on practically every server on the planet. The \"container\" is the kernel doing its job; Docker is merely the convenient tool that asks for it.",[19,66,67,68,71,72,75],{},"The trouble starts when you want the same thing on a Mac. The macOS kernel (XNU) ",[23,69,70],{},"has no namespaces and no cgroups",", and on top of that, container images ship binaries compiled for Linux: the MySQL inside the image is a Linux executable, not a macOS one. The inescapable conclusion: to run a Linux container on a Mac you need a real Linux kernel running somewhere. In other words, ",[23,73,74],{},"a virtual machine",". Always. There is no way around it.",[19,77,78],{},"Everything sold as \"Docker on Mac\" is really a Linux VM in disguise, and the odd behaviours anyone notices in their first week leak out of the seams of that disguise:",[80,81,82,101,115],"ul",{},[83,84,85,88,89,92,93,96,97,100],"li",{},[23,86,87],{},"Slow disk",": bind mounts (",[27,90,91],{},"-v .\u002Fcode:\u002Fapp",") cross the macOS↔VM border through a shared-file protocol. That's why ",[27,94,95],{},"composer install"," or ",[27,98,99],{},"npm install"," over a mounted volume is painfully slow on a Mac and perfectly normal on Linux.",[83,102,103,106,107,110,111,114],{},[23,104,105],{},"Weird networking",": ",[27,108,109],{},"host.docker.internal",", a ",[27,112,113],{},"--network host"," that doesn't really work... because the container's network lives inside the VM, not on your Mac.",[83,116,117,120],{},[23,118,119],{},"Hijacked RAM",": Docker Desktop's VM reserves however many gigabytes you configured and stays up as long as the app runs, whether you have 0 or 20 containers going.",[14,122,124],{"id":123},"what-apple-is-doing-differently","What Apple is doing differently",[19,126,127,128,131,132,135],{},"Here's the interesting technical part. Docker Desktop solves the problem with ",[23,129,130],{},"one big shared Linux VM"," running ",[27,133,134],{},"dockerd"," inside, and all your containers are processes of that single VM sharing its kernel. It is, quite literally, \"a VirtualBox with Docker inside\".",[19,137,138,139,142,143,146],{},"Apple went the opposite way: ",[23,140,141],{},"one micro-VM per container",". Each container boots its own lightweight virtual machine with a minimal Linux kernel and a tiny init (",[27,144,145],{},"vminitd",", written in Swift) that executes the container's process directly — no daemon anywhere. When the container dies, its VM vanishes with it.",[19,148,149,150,153,154,157],{},"Apple didn't invent this. It's the same pattern as ",[23,151,152],{},"AWS Firecracker"," (what runs every Lambda function) and ",[23,155,156],{},"Kata Containers",": micro-VMs so cheap to spin up that you can afford one per workload. The novelty is shipping it out of the box on a development laptop.",[19,159,160,161,164],{},"A framing we like: ",[23,162,163],{},"on Linux, a container is a process disguised as a machine. On Apple's Mac, it's a machine disguised as a process."," The user experience looks similar; the plumbing is exactly inverted.",[14,166,168],{"id":167},"putting-the-claims-to-the-test","Putting the claims to the test",[170,171,173],"h3",{"id":172},"it-uses-less-ram-than-docker-desktop-half-true","\"It uses less RAM than Docker Desktop\" — half true",[19,175,176,177,180],{},"At idle, yes: zero containers = zero VMs = zero RAM, whereas Docker Desktop's VM claims its gigabytes just for existing. But each Apple micro-VM boots its own kernel and gets 1 GB allocated by default, so with many simultaneous containers the maths flips: N kernels weigh more than one shared kernel. The saving is real if you spin up the occasional standalone container; for an eight-service ",[27,178,179],{},"compose"," stack, not so much.",[170,182,184],{"id":183},"hardware-level-isolation-marketing-phrasing-real-substance","\"Hardware-level isolation\" — marketing phrasing, real substance",[19,186,187,188,191],{},"In Docker, two containers share a kernel: one kernel exploit from inside a container compromises all the others, and namespace escapes are a vulnerability class that shows up every single year. With one VM per container, escaping means breaking the hypervisor — the CPU's virtualisation extensions, hence \"hardware\" — which is a far harder wall. It's the exact sales pitch behind Firecracker at AWS. That said: it's a ",[23,189,190],{},"multi-tenancy"," argument, not a local-development one. For your throwaway MariaDB it makes no difference whatsoever.",[170,193,195],{"id":194},"sub-second-startup-true-and-the-most-polished-part","\"Sub-second startup\" — true, and the most polished part",[19,197,198],{},"Minimal kernel, minimal rootfs, no daemon. Starting a container is practically indistinguishable from launching it on native Linux. Apple did its homework here.",[170,200,202],{"id":201},"the-toll-that-remains","The toll that remains",[19,204,205],{},"Bind mounts still cross the macOS↔Linux border (virtiofs), so shared file access will keep being slower than native Linux. They've padded the workaround; they haven't removed it. Physics doesn't change: on a Mac there will always be a VM in the middle; on Linux, never.",[14,207,209],{"id":208},"the-irony-of-the-move","The irony of the move",[19,211,212,213,216],{},"There's something amusing about the fact that, after years of complaints about Docker Desktop being \"heavy\", Apple's alternative boots ",[23,214,215],{},"an entire VM with its own kernel for every container",". On paper that sounds heavier still; Apple's bet is that on its silicon, micro-VMs are so cheap you won't notice.",[19,218,219,220,223],{},"But look at what people actually criticised about Docker. Nobody questioned the container concept — that one won outright: OCI images are the standard and Apple adopts them as-is, no proprietary format. The complaints targeted ",[23,221,222],{},"Docker Desktop the product",": the always-on VM, the disk performance, the root daemon and, above all, the 2021 licence change, when Docker Inc. started charging businesses a subscription. That's where Colima, OrbStack and Podman Desktop came from — and now Apple, running its classic play: the standard already exists, the dominant implementation has friction and a licence toll, so let's bake it into the operating system for free.",[19,225,226],{},"What's at stake isn't Docker the concept. It's Docker Desktop the product.",[14,228,230],{"id":229},"limitations-before-you-get-excited","Limitations before you get excited",[80,232,233,239,246,252],{},[83,234,235,238],{},[23,236,237],{},"Apple Silicon only"," (M1 onwards). No Intel.",[83,240,241,242,245],{},"Version 1.0 requires ",[23,243,244],{},"macOS 26 (Tahoe)","; support on older releases is limited or non-existent.",[83,247,248,251],{},[23,249,250],{},"No full Docker Compose equivalent."," For a project with several linked services, Docker Desktop or OrbStack remain more comfortable today.",[83,253,254],{},"The tooling ecosystem (CI, IDE integrations, team scripts) still revolves around Docker.",[14,256,258],{"id":257},"what-changes-for-you-probably-nothing-on-the-server","What changes for you (probably nothing on the server)",[19,260,261,262,265,266,268],{},"If you run servers: ",[23,263,264],{},"nothing",". Containers on Linux are native, there's nothing to fix there, and deployments will keep being Docker or Podman on Linux as always. Apple's ",[27,267,29],{}," doesn't compete on that turf and doesn't try to.",[19,270,271,272,275,276,41],{},"If you develop on an Apple Silicon Mac: it's a serious alternative to keeping Docker Desktop installed for standalone containers — a test database, an isolated PHP, a throwaway environment — with no permanent VM eating resources and no licence in the way. It installs from a ",[27,273,274],{},".pkg"," on the GitHub releases page and starts with ",[27,277,278],{},"container system start",[19,280,281,282,284],{},"And if your project is a many-service ",[27,283,179],{}," stack: for now, stay where you are. The 1.0 marks a stable API contract, not feature parity.",[14,286,288],{"id":287},"references","References",[80,290,291,300,307,314,321],{},[83,292,293],{},[294,295,299],"a",{"href":296,"rel":297},"https:\u002F\u002Fgithub.com\u002Fapple\u002Fcontainer",[298],"nofollow","apple\u002Fcontainer — GitHub",[83,301,302],{},[294,303,306],{"href":304,"rel":305},"https:\u002F\u002Fgithub.com\u002Fapple\u002Fcontainerization",[298],"apple\u002Fcontainerization — GitHub",[83,308,309],{},[294,310,313],{"href":311,"rel":312},"https:\u002F\u002Fopensource.apple.com\u002Fprojects\u002Fcontainerization\u002F",[298],"Containerization — Apple Open Source",[83,315,316],{},[294,317,320],{"href":318,"rel":319},"https:\u002F\u002Fthenewstack.io\u002Fapple-containers-on-macos-a-technical-comparison-with-docker\u002F",[298],"Apple Containers on macOS: A Technical Comparison With Docker — The New Stack",[83,322,323],{},[294,324,327],{"href":325,"rel":326},"https:\u002F\u002Fanil.recoil.org\u002Fnotes\u002Fapple-containerisation",[298],"Under the hood with Apple's new Containerization framework — Anil Madhavapeddy",{"title":329,"searchDepth":330,"depth":330,"links":331},"",2,[332,333,334,335,342,343,344,345],{"id":16,"depth":330,"text":17},{"id":44,"depth":330,"text":45},{"id":123,"depth":330,"text":124},{"id":167,"depth":330,"text":168,"children":336},[337,339,340,341],{"id":172,"depth":338,"text":173},3,{"id":183,"depth":338,"text":184},{"id":194,"depth":338,"text":195},{"id":201,"depth":338,"text":202},{"id":208,"depth":330,"text":209},{"id":229,"depth":330,"text":230},{"id":257,"depth":330,"text":258},{"id":287,"depth":330,"text":288},"2026-06-11","Apple has shipped version 1.0 of its container tool for macOS. We explain why containers are only native on Linux, what makes Apple's micro-VM model different from Docker Desktop, and what actually changes (and what doesn't) for developers and server admins.","md","\u002Fog\u002Fog-default.png",{},true,"apple-container-vs-docker-linux","\u002Fen\u002Fblog\u002Fapple-container-vs-docker-linux",{"title":8,"description":347},"en\u002Fblog\u002Fapple-container-vs-docker-linux",[357,358,359,360],"Containers","Docker","Linux","macOS","OcojIz_LWj2XtQiLJkrN-2uytj2ZO6pcYA6XJW7hcAw",1781154907961]