Encore llevó las microVMs de Linux a Apple Silicon
En pocas palabras: El equipo de Encore creó Crackling, un daemon y CLI open source que bootea imágenes OCI como microVMs con una única API: usa Firecracker en Linux y Virtualization.framework en macOS, porque ninguna Mac incluye KVM, el módulo que exige el hipervisor de AWS.
El equipo de Encore reconstruyó el stack de microVMs de Linux para Apple Silicon: presentó Crackling, una API única que bootea las mismas imágenes OCI como máquinas virtuales ligeras Apple Silicon, con Firecracker en Linux y Virtualization.framework en macOS, según publicaron en su blog.
Una microVM de este tipo combina el aislamiento de una máquina virtual completa con un arranque casi tan veloz como el de un contenedor. Firecracker, el hipervisor open source creado por AWS, es el estándar del rubro, pero exige un host Linux con KVM, algo que ninguna Mac trae. Crackling es un daemon y CLI open source de Encore que cierra esa brecha: levanta imágenes OCI como microVMs en Linux y en macOS con un único protocolo.
En síntesis
- Firecracker corre los builds de Encore desde mediados de 2022, pero siempre en un servidor Linux remoto: ningún Mac tiene KVM, el módulo que el hipervisor necesita.
- Los mantenedores de Firecracker rechazaron un proof of concept para macOS y dejaron claro que no planean soportarlo “any time soon”, según relata Encore.
- Crackling unifica dos hipervisores bajo una sola API: Firecracker en Linux y Virtualization.framework (VZ) en macOS, con el mismo agente dentro del guest comunicándose por vsock.
- Reconstruir el pipeline de imágenes fue lo más difícil: convertir capas de Docker en un rootfs booteable, desenvolver kernels comprimidos y armar initramfs sin root ni loop mounts.
- El resultado práctico: los ingenieros buildean en su laptop con breakpoints locales y logs al toque, mientras Firecracker sigue mandando en producción.
¿Por qué Encore no podía correr Firecracker en las Mac de sus ingenieros?
Porque Firecracker necesita un host Linux con KVM y ningún Mac lo trae. Desde mediados de 2022, cada build de Encore corría dentro de una microVM en una máquina compartida en un datacentro, a la que cada ingeniero entraba por SSH y Tailscale. Desarrollar el sistema de builds significaba, ni más ni menos, desarrollarlo desde otra computadora.
Ponele que querías probar un cambio en el guest. Un script leía tu usuario y tu puerto de un archivo CUE gitignoreado (todos compartían el host, así que había que acordarse de no chocar puertos), cross-compilabas con GOOS=linux GOARCH=amd64, rsynceabas los binarios y contabas los archivos transferidos para decidir qué reiniciar (sí, en serio).
Y las imágenes eran peor. Subías el cambio, rsynceabas, reiniciabas el contenedor con un tercer SSH, mirabas el log con tail a través de la conexión y, si algo explotaba, volvías a empezar, porque el breakpoint local nunca iba a saltar, el profiler había que copiarlo primero a la caja y cada iteración pasaba por reextraer la imagen entera en un host que otros ingenieros estaban usando al mismo tiempo.
¿Te imaginás debuggear así todos los días? Exacto.
Ese circuito duró cuatro años. Funcionaba, sí. Pero en una empresa cuyo producto promete que la infraestructura siga al código, la parte que convertía un git push en una app corriendo era justo la única que no podías correr en la máquina donde escribís software. Si alguna vez administraste un servidor remoto, el ritual te va a sonar: SSH, editar, sincronizar y cruzar los dedos. Para más detalles técnicos, mirá el fenómeno de Omarchy en GitHub.
¿Qué es Firecracker y por qué Encore lo eligió para sus builds?
Firecracker es el hipervisor open source que AWS desarrolló para su infraestructura serverless. La premisa: agarrá una máquina virtual y sacale todo el hardware emulado que un kernel Linux no necesita. Lo que queda es una microVM con aislamiento de VM y costo de arranque cercano al de un contenedor, tal como lo describe el post de Encore.
Para builds, la elección es obvia. Un build ejecuta código que no controlás: dependencias que bajás, scripts de terceros, tu propio código en estado experimental. Un contenedor comparte el kernel del host; una microVM bootea kernel propio y muere sin dejar rastros. Encore corre cada build así desde mediados de 2022, y el proyecto sigue abierto en su repositorio de GitHub.
¿Se puede correr Firecracker en una Mac de forma nativa?
No, y no esperes que cambie pronto. Firecracker depende de KVM, que solo existe en Linux. Cuando Encore les llevó un proof of concept funcional construido sobre Virtualization.framework, los mantenedores lo rechazaron y avisaron que no planean soportar macOS “any time soon” (en el corto plazo), según relata el equipo de Encore.
Antes de escribir una línea de Crackling, miraron lo que ya existía. El framework de virtualización nativo de Apple llegó a su versión 1.0 en junio de 2026 (documentación oficial acá), proyectos como Lima o UTM vienen levantando VMs Linux en Mac hace años, y podman puede correr Firecracker sin modificarlo anidándolo en QEMU dentro de una VM Linux, aunque solo en chips M3 o posteriores con macOS 15.
Ninguna opción cubría los dos mundos. La ruta anidada te deja dentro de una VM Linux y en el subconjunto de laptops que la soporta. Adoptar cualquiera hubiese significado mantener una segunda forma de buildear, con comportamiento distinto, que solo existe en notebooks. O sea, el mismo problema con otro disfraz.
¿Cómo funciona Crackling, la API única sobre dos hipervisores?
Crackling es un daemon y un CLI que bootean imágenes OCI como microVMs Linux en las dos plataformas. El CLI habla gRPC con el daemon; el daemon elige backend en tiempo de compilación: Firecracker en Linux, Virtualization.framework en macOS. Adentro del guest corre un único agente, el mismo binario en ambos casos, que se comunica por vsock. El protocolo no cambia nunca.
El core es un crate independiente de cualquier hipervisor: describe la máquina en una configuración, la trackea en runtime y ambos backends implementan los mismos traits, con tests que usan un backend en memoria. Como solo un backend existe por target, el dispatch es estático. Simple y efectivo.
Lo fino está en las capacidades. Antes de crear cualquier máquina, cada backend reporta qué soporta en el host actual; si pedís algo que no está (Mmds, VirtioFs, Rosetta, MemoryBalloon, Entropy, Vsock), el error nombra la feature y la petición muere en el borde de la API. Nada de crashes misteriosos a mitad del boot. El código está publicado en el repositorio de Crackling.
El ciclo de vida también difiere. En Linux, cada VM es un proceso hijo separado que habla REST sobre un Unix socket y puede sobrevivir al daemon: persisten PID y hora de inicio para que la reutilización de PIDs no haga que un registro viejo apunte a un proceso ajeno. En macOS, las máquinas VZ viven dentro del proceso del daemon y mueren con él; restaurar snapshots ahí devuelve error directo.
¿Cuáles son las diferencias técnicas entre Firecracker y Virtualization.framework?
Los dos bootean la misma imagen y hablan con el mismo agente, pero abajo son bestias distintas. Firecracker da primitivas crudas de red y su servicio de metadatos MMDS; VZ apuesta por conveniencias integradas. Esta tabla resume el contraste según el post de Encore: Cubrimos ese tema en detalle en nuestra guía sobre DNS autoritativos.
| Característica | Firecracker (Linux) | Virtualization.framework (macOS) |
|---|---|---|
| Requisito de host | Linux con KVM | macOS en Apple Silicon |
| Red | Tap devices en el host | Dispositivo NAT integrado |
| Servicio de metadatos | MMDS incluido | No disponible (error Mmds) |
| Compartir directorios | Sin equivalente directo | Incluido (VirtioFS) |
| Binarios x86 en guest arm64 | Sin equivalente directo | Traducción Rosetta |
| Ciclo de vida | Proceso hijo separado, puede sobrevivir al daemon | Vive dentro del proceso del daemon |
| Snapshots | Disponibles donde el backend lo permite | Restaurar devuelve error |
Ojo con un detalle: la negociación es explícita. Si tu flujo necesita MMDS y estás en una Mac, te enterás al pedirlo, no tres semanas después en producción. Ese diseño me parece el aporte más copiable de todo el proyecto.
¿Por qué reconstruir el pipeline de imágenes fue el desafío más grande?
La respuesta corta: ninguno de los dos hipervisores bootea nada hasta tener un kernel descomprimido y un rootfs, y todo el toolchain que hacía eso vivía en Linux. Convertir una imagen OCI en un filesystem booteable exige root y loop mounts, y en macOS no existe ninguna de las dos cosas. Firecracker, además, bootea un block device mientras Docker produce capas: no había herramienta que hiciera la conversión, así que la escribieron ellos.
El kernel traía su propia trampa. Las distros arm64 traen un Image.gz, un ejecutable EFI que envuelve un payload comprimido que el firmware normalmente descomprime al arrancar. Acá no hay firmware, así que lo desenvuelven a mano: identifican el formato por firmas y leen offset, tamaño y compresión del header. Y si le pasás a VZ un kernel comprimido, falla al arrancar con un error interno “genérico” y sin detalle alguno. Perdieron una tarde entera re-firmando binarios, sospechando del entitlement de virtualización, antes de mirar el kernel. (Spoiler: no era el entitlement.) Ahora chequean la firma en el offset 0x38 y avisan antes de intentar bootear.
El resto del pipeline se resolvió en userspace: aplican las capas OCI en proceso, honrando los whiteouts .wh., escriben el resolv.conf que el guest necesita para tener DNS y arman un initramfs, un archivo cpio formato newc dentro de un stream gzip. Hasta el pull de la imagen exigió un resolver de plataforma custom, porque el default compara contra el OS del host y jamás matchea una imagen linux/arm64 pedida desde una Mac.
¿Por qué Virtualization.framework complicó todo con el manejo de hilos?
VZ impone una regla dura: toda operación sobre una VM debe correr en la serial dispatch queue que la creó, y sus objetos de configuración no son thread-safe. El daemon de Crackling, en cambio, es async con tokio, que mueve futures entre worker threads cuando se le antoja. Las dos reglas no conviven.
La solución: crear y acceder a cada VM desde una única cola serial global del proceso. El registro de VMs solo es visible para closures despachadas a esa cola, y la mitad async despacha un closure que lleva únicamente datos Send y espera la respuesta. El compilador, de hecho, prohibe capturar objetos VM no-Send. Bajaron la configuración en dos fases (primero una estructura Send-only en tokio, después el objeto VZ en la cola) y el dispose también ocurre en la cola. Es ingeniería fina, de la que no se habla en los tweets pero decide si el sistema funciona. Ya lo cubrimos antes en comparativa de herramientas de CI/CD.
¿Cómo cambió el día a día en Encore después de Crackling?
Dar de alta un ingeniero en el viejo mundo exigía un script que entraba como root a la máquina compartada, creaba tu usuario con la clave pública de github.com/tu-usuario.keys y copiaba las imágenes de VM a tu home. Ahora el mismo entorno vive en tu laptop. Breakpoints que saltan, logs sin tail por SSH.
El cambio cultural es el que más me gusta: el loop se acortó tanto que probar algo especulativo dejó de ser una decisión de presupuesto. Y la higiene de ingeniería acompaña: cada pull request compila y testea ambos backends, un runner x86_64 Ubuntu para Firecracker y uno arm64 macOS para VZ, mientras la lógica agnóstica del daemon se prueba contra un backend mock. Los tests de VZ no necesitan hipervisor, firma de código ni imagen de guest.
¿Qué significa Crackling para el futuro de las máquinas virtuales ligeras Apple Silicon?
Que el patrón “la misma imagen en producción y en mi laptop” dejó de ser privilegio de quien desarrolla en Linux. Crackling es open source, así que cualquier equipo con builds en Firecracker puede tomar la arquitectura: un core agnóstico, backends por plataforma, un agente de guest común y negociación explícita de capacidades.
Mi lectura, con la distancia debida: VZ madurando (versión 1.0 en junio de 2026) y Apple empujando la virtualización nativa sugieren que van a aparecer más herramientas de este estilo. Docker Desktop no desaparece mañana, pero para aislar cargas Linux en una Mac, las microVMs son la apuesta más limpia que veo hoy. Eso sí, tomalo con pinzas: el caso de Encore es específico, y VZ todavía arrastra límites reales, como snapshots que no se restauran o features que quedan del lado Linux.
Errores comunes al trabajar con microVMs en Mac
Viendo cómo viene la mano, estos tropiezos se van a repetir mucho. Ahí van los cuatro más probables:
- Confundir contenedor con microVM. Docker comparte el kernel del host; una microVM bootea kernel propio. Si el riesgo es ejecutar código que no controlás, el contenedor solo no alcanza.
- Bootear un kernel comprimido en VZ. Virtualization.framework falla con un error interno “genérico” y sin detalle si le pasás un Image.gz. Descomprimilo antes, o verificá la firma en el offset 0x38 como hace Crackling.
- Asumir que una imagen OCI arranca sola. Hay que resolver la plataforma correcta (linux/arm64 desde una Mac), aplicar los whiteouts .wh. y preparar un initramfs. El resolver por defecto compara contra el OS del host y nunca matchea.
- Correr Firecracker dentro de Docker sin preparar la red. Sin pasar /dev/kvm y /dev/net/tun al contenedor, y sin un bridge interno para los tap devices, el hipervisor no arranca.
Preguntas Frecuentes
¿Cómo puedo correr Firecracker en mi Mac?
De forma directa no se puede: Firecracker requiere KVM y ese módulo solo existe en Linux. Tus opciones son anidarlo en QEMU dentro de una VM Linux (funciona en chips M3 o posteriores con macOS 15, vía podman) o usar una herramienta como Crackling, que bootea las mismas imágenes OCI con Virtualization.framework. En OrbStack frente a Multipass en Mac profundizamos sobre esto.
¿Qué es Virtualization.framework y para qué sirve?
Es el framework nativo de Apple para crear y gestionar máquinas virtuales en macOS, y alcanzó la versión 1.0 en junio de 2026. Sirve para bootear sistemas operativos completos sobre Apple Silicon usando el hipervisor del sistema, y es el backend que Crackling utiliza en Mac.
¿Cuál es la diferencia entre Firecracker y Docker en macOS?
Docker en Mac corre contenedores dentro de una VM Linux oculta que comparte su kernel; Firecracker bootea una microVM con kernel propio y aislamiento total. Firecracker tampoco corre de forma nativa en macOS: necesita un host Linux con KVM o una capa intermedia como Crackling.
¿Puede Crackling reemplazar Docker Desktop en desarrollo?
Para el caso de uso de Encore, convertir imágenes OCI en microVMs aisladas para builds, cubre el flujo completo. Pero Crackling es un daemon y CLI enfocado en microVMs: si dependés de piezas del ecosistema Docker como compose, hoy no es un reemplazo uno a uno.
¿Crackling y Firecracker son gratuitos y open source?
Sí, los dos. Firecracker es el hipervisor open source de AWS con repositorio público en GitHub, y Encore publicó Crackling en github.com/encoredev/Crackling. Podés inspeccionar el código, auditarlo y adaptarlo a tu propio flujo de trabajo.
Conclusión
“Maybe we should have just moved everyone to Linux” (quizás deberíamos haberle pedido a todos que pasaran a Linux), arranca el post de Encore, y la frase resume el dilema de miles de equipos: producción en Linux, laptops en macOS. En vez de migrar gente, migraron el stack: reemplazaron cuatro años de builds remotos con una capa que respeta las reglas de cada hipervisor y expone una sola API.
Si tu equipo vive esa misma grieta, el código está abierto y la arquitectura está documentada. La lección central aplica en cualquier stack: negociá capacidades de forma explícita en el borde de la API, antes de descubrirlas a las tres de la mañana en producción.
