Las microVM de Firecracker en lenguaje claro: una VM de verdad que arranca en una fracción de segundo

Si has leído algo sobre cómo ejecutar de forma segura código generado por IA, habrás visto la palabra microVM, normalmente junto a Firecracker. Se suele explicar como «una VM ligera» (cierto, poco útil) o con un diagrama de las entrañas del kernel. Esta es la versión intermedia.

Dos opciones más antiguas y por qué ninguna encaja

Empecemos por las dos cosas entre las que se sitúa una microVM.

Un contenedor es un grupo de procesos normales en tu máquina a los que el kernel ha accedido a engañar. Los namespaces les muestran su propio sistema de archivos, su lista de procesos y su red; los cgroups limitan cuánta CPU y memoria pueden usar. Arranca en milisegundos porque no se inicia nada nuevo. Pero todos los contenedores de un host hablan con el mismo kernel. Un fallo del kernel alcanzable desde un contenedor es una salida para todos.

Una máquina virtual trae su propio kernel. La CPU del host, mediante virtualización por hardware (KVM en Linux), ejecuta al invitado como si tuviera su propio ordenador. La frontera es el hipervisor, que expone mucho menos que los cientos de llamadas al sistema de un kernel. El precio es el peso. Una VM clásica emula un PC entero: firmware, un bus PCI, controladores USB, una tarjeta gráfica, a veces una tarjeta de sonido. Arranca pasando por todo eso, tarda de segundos a minutos y cada instancia arrastra decenas o cientos de megabytes de sobrecarga.

Una analogía que aguanta bastante bien: los contenedores son pisos de un mismo edificio que comparten cimientos, tuberías y cableado. Las VM son casas separadas. Las casas son vecinas más seguras, pero nadie construye una para una visita de 20 segundos.

Lo que elimina Firecracker

Firecracker es un monitor de máquinas virtuales (el programa que configura y ejecuta una VM sobre KVM) escrito en Rust y liberado como código abierto en 2018. Se creó para un único trabajo: ejecutar enormes cantidades de cargas de corta duración, que no se fían unas de otras, sobre hardware compartido. Lo consigue sobre todo eliminando cosas:

• Sin firmware ni detección de hardware. El kernel se carga directamente en memoria y se inicia. Nadie busca dispositivos que no existen.
• Un modelo de dispositivos diminuto. Una tarjeta de red, un dispositivo de bloques, una consola serie y algunos más, todos virtio (dispositivos diseñados para máquinas virtuales en lugar de imitar los físicos). Nada de USB, gráficos ni PCI.
• Una base de código pequeña y segura en memoria. Menos código emulando dispositivos significa menos sitios para un fallo que permita al invitado alcanzar el host.
• Una jaula alrededor del propio VMM. Cada proceso de Firecracker se ejecuta dentro de un chroot, con filtros seccomp sobre sus propias llamadas al sistema y cgroups sobre sus recursos. Si algo escapara del invitado, acabaría en una jaula, no en el host.

Las cifras publicadas por el propio proyecto son espacio de usuario en apenas 125 ms y menos de 5 MiB de sobrecarga de memoria por microVM. Son los mejores valores de laboratorio; una sandbox real también necesita preparar su disco y su red y esperar a un agente interno listo para aceptar comandos, por eso la nuestra está lista en un segundo aproximadamente. Sigue siendo lo bastante cercano a la velocidad de un contenedor como para crear una por tarea y tirarla después.

Contenedor frente a microVM, en la práctica

La fila que importa es la segunda. Con un contenedor, la pregunta «¿puede escapar este código?» se convierte en «¿hay algún fallo alcanzable en el kernel del host?». Con una microVM, se convierte en «¿hay un fallo en el hipervisor o en un puñado de dispositivos virtuales?». La segunda superficie es mucho menor, y es la que las plataformas en la nube ya defienden para su propio alojamiento multiinquilino.

A qué renuncias

Una microVM no es una mejora gratuita.

• Sin GPU ni pantallas. Sirve para ejecutar código, no para escritorios ni gráficos.
• Menos dispositivos, menos flexibilidad. Todo lo que espere hardware real o una larga lista de módulos del kernel no se sentirá en casa.
• Las fronteras siguen necesitando políticas. Una microVM con tráfico saliente abierto puede seguir enviando tráfico que no quieres; una con tus claves de API dentro puede seguir filtrándolas. El aislamiento protege al host del invitado, no a tus secretos del código al que se los diste.

Cómo la usan nuestras sandboxes

Cada sandbox de EQVPS es una microVM de Firecracker con su propio kernel, desde 0.25 vCPU y 512 MB hasta 8 vCPU y 16 GB. Incluye Python 3.12, Node.js 22, bash, git y curl, tiene internet saliente y ningún puerto entrante. Las sandboxes efímeras se eliminan cuando terminas; las persistentes conservan su disco, y pausar una escribe una instantánea de la microVM en disco, de modo que no cuesta nada hasta que se reanuda. Las instantáneas en pausa se guardan 14 días. Después la sandbox se borra y su id responde 410 sandbox_deleted.

Elegimos microVM en lugar de contenedores por una razón: el código que corre en una sandbox es, por diseño, código que nadie ha revisado. La salida de un agente de IA, el pull request de un desconocido, un benchmark de mil programas escritos por un modelo. Para eso, un kernel propio es la frontera por la que merece la pena pagar. Los detalles de lo que hemos construido alrededor —tarifas, cuotas, el límite de 55 segundos para comandos síncronos— están en la documentación de sandboxes.

Si quieres comparar esta frontera con las demás opciones en más detalle, niveles de aislamiento para código no fiable pone procesos, contenedores, microVM y VM completas uno al lado del otro. Y si lo que te llamó la atención fue el precio por segundo, cómo funciona de verdad la facturación por segundo muestra la aritmética.