We Rebuilt the Linux MicroVM Stack on Apple Silicon

A suggestion to the author -- don't outsource your writing to AI, or, if you do, go over it with a fine-tooth comb and remove every trace of Claudisms from it.

I read the subtitle: "What it takes to boot the same microVMs on Apple's hypervisor, and the one capability Apple will not let you have." and immediately navigated away.

What an awful blog renderer that, in Firefox, works when scrolling with the trackpad, but doesn't work when using keyboard arrow keys or pageUp/down: I get blank pages when scrolling with the keyboard beyond the initial viewport.

I saw this blog post title and wanted to read it, as I thought this is something we really wanted when I worked back at Encore - and lo and behold what website I ended up on!

Great work lads, seeing those old shell scripts brought back memories, but this is awesome to see you've solved the problem now to make your own lives easier!

Any plans to open source crackling? I was looking into cross platform microVM's after reading about sbx recently.

This article was made for LLMs reading, not for human reading.

I wonder how necessary/useful this is, in light of the amazing smolvm microvms from https://smolmachines.com.

(Not snark, not affiliated, just happy and impressed with smolvm and genuinely curious.)

By experience, getting Firecracker to run well on M-series macs is quite the undertaking. I'm not at all surprised Encore decided to take this path considering their customer base!

At Lovable we decided to spend ~1 engineering month getting our sandbox infrastructure to be 100% runnable on Mac and on Linux with predictable builds using Bazel etc.

But we actively decided to take a different route than Encore and run nested virtualization, which on macOS means vfkit -> QEMU -> Kind + Firecracker vm(s). It's been invaluable to get the same development and testing tools on both platforms tbh.

> most engineers at Encore develop on a Mac

They are solving the wrong problem.

VZ.framework is very limited, Hypervisor.framework is the better analogue to KVM

Very hard to read

Rebuilding MicroVMs natively on Apple Silicon usually cuts virtualization overhead massively, but Hypervisor.framework DX and virtio device parity are the real bottlenecks.

Hey everyone - author of the article here! Happy to take questions.

I don't use MacOS.

I don't use MacOS because it is not Open Source.

I don't use Windows.

I used Windows extensively in the past, but I don't use it in 2026, because it is not Open Source.

Anytime you're dealing with a closed source OS, you're dealing with the following things:

1) Extra time/effort/complexity to make your programs work correctly.

2) Extra time/effort/complexity to make your already working working programs keep working through OS version updates, upgrades, patches, etc., etc.

This article (AI written, not AI written, I don't care) describes something that is overly complex (proof that you don't have and/or cannot access the source code of the underlying operating system) and something which could potentially fail when Apple releases its next OS or OS upgrade...

If you switch to an Open Source operating system (and I'm not trying to shill for Linux here -- OpenBSD, etc., any open source Operating System could work too), then most of these problems will disappear -- or at least be reduced rather significantly.

But what I'm most concerned about is the complexity...

Now, you're welcome to engineer whatever additional complexity above Apple's stack -- many companies do this and are more than willing to pay the price in additional time, resources, programmers, tech people handling whatever issues arise, as they arise.

I'm not against Apple -- I think their products have beautiful aesthetics, and every company, every producer of physical products on the planet could take a lesson from their design teams. Their products are absolutely stunningly visually appealing!

But Apple in turn, could take a lesson from Linux and every other open source OS on the planet.

I personally will not develop for any Apple product unless and until Apple open sources their OS'es.

If code that I write coincidentally runs on an Apple product, hey that's a happy coincidence! Yay!

But I never expect it to, and I never expect to keep working across OS versions and upgrades.

If anyone thinks I'm being unfair to Apple, then I'll state for the record that I have the exact same expectations (or negative expectations, as the case may be!) about Microsoft Windows!

Closed source OS'es lead to complexity, work-arounds ("oh no, API call <abc> isn't working the way we thought it would under these conditions -- well, use this work-around and call API <xyz> with this unnecessary and overly complex data structure after making 3 other unnecessary API calls and then you need to do the following additional steps..."), and software breaking over time over OS version upgrades, updates, patches, and the like.

On the one hand, I'm very glad that this article is bringing micro VM's to Apple.

That's a good idea!

(But on the other hand, I have to ask if the complexity is worth it... but I'm not the guy who pays these guys' salaries or the future support guys' salaries, so I can't determine if it is or isn't, if the trade-off is worth it!)

On the positive side though, bringing Micro VM's to Apple is a good idea, at least in its purest idea form ("we want to add functionality X to platform Y" -- there's nothing wrong with the intention to add value to something -- in fact, quite the opposite! The whole of Western Civilization is based on that idea!)

Four years on a shared remote machine before building the local backend is a good lesson in when to invest in dev tooling versus living with the workaround.

I think Encore is great and do really cool things, but this post is AI;DR from the first sentence.

"You can even get /dev/kvm inside a Linux VM on an M3 or later running macOS 15, which runs Firecracker unmodified."

I'm very confused why any SWE is on a M1 or M2 Mac. I've always gotten a new machine at $CORP every 2 years...

This seems great tech but the obvious obvious LLM slop writing is just so incredibly off-putting. We read LLM slop everyday ourselves, but now we have to read it everywhere else too. Is this stuff so hard to just write oneself ??

I just encountered the `com.apple.private.virtualization` entitlement limitation just last night, wanting to use VZVirtualMachine private AccessorEndpoint api. There's lot of useful stuff hidden in Apple's Private API space.

Great write up! I enjoy seeing others working in the same problem space.

AI written...

AI Slop; Did Not Read

Great article!

nice

[dead]

[flagged]