¿Qué es Firecracker y por qué a todas las empresas de infraestructura de agentes les importa?

Cada día, AWS Lambda ejecuta billones de invocaciones de funciones. AWS Fargate programa millones de contenedores. Cada uno de ellos es una máquina virtual completa, con su propio kernel, arrancada en una fracción de segundo.

¿Cómo? Con unas 50.000 líneas de Rust llamadas Firecracker, que existe porque la industria finalmente admitió que un contenedor Linux que controla el uso de recursos nunca fue diseñado para ser un límite de seguridad.

El problema del aislamiento

Cada contenedor Docker en tu portátil son tres características del kernel de Linux disfrazadas:

• Los namespaces son vendas en los ojos. Un proceso dentro de uno obtiene una vista privada del sistema: su propia lista de PIDs, pila de red, tabla de montajes, nombre de host e IDs de usuario. El PID 1 dentro del contenedor es algún PID aleatorio en el host; el contenedor ni siquiera puede ver los otros procesos.
• Los cgroups son presupuestos. Los grupos de control son la capa de contabilidad y limitación de velocidad del kernel. Limitan cuánta cantidad de CPU, memoria, IO de disco y ancho de banda de red que un árbol de procesos puede consumir.
• seccomp + capabilities son listas blancas. Las capabilities dividen los poderes de root en unos ~40 privilegios separados (enlazar puertos bajos, cargar módulos del kernel, montar sistemas de archivos, etc.) para que puedas concedas solo los que necesitas. seccomp es un filtro por proceso que decide qué llamadas al sistema (la única API del espacio de usuario hacia el kernel) puede hacer el proceso.

Puedes comprobarlo tú mismo sin tener Docker instalado:

Todo lo demás que hace Docker (capas de imagen, registros, DNS) es orquestación sobre esto.

Toda esa protección pasa por un solo kernel de Linux, de unos 30 millones de líneas de código que exponen más de 400 llamadas al sistema. Cada contenedor en el host llama a ese mismo kernel. Un error en cualquiera de esas llamadas y es el fin del juego para todos los inquilino en esa máquina.

Las máquinas virtuales completas resuelven el aislamiento por la fuerza bruta: cada VM tiene su propio kernel.

Las CPUs modernas tienen un "modo invitado" que ejecuta las instrucciones del invitado en el silicio real. El host solo se involucra cuando el invitado hace algo privilegiado (toca hardware real, falla, recibe una interrupción). Un hipervisor es la capa delgada que arbitra esos momentos.

Linux incluye su hipervisor como un módulo del kernel llamado KVM, expuesto en /dev/kvm. Se apoya en las extensiones de virtualización del hardware (vmx en Intel, svm en AMD):

El problema de las VMs completas son lentas y pesadas. Una VM clásica de QEMU emula un PC imaginario completo (BIOS, bus PCI, controladora IDE, tarjeta VGA, teclado PS/2) porque eso es lo que un sistema operativo de 1998 esperaba para arrancar. La imagen cientos de megabytes. El arranque lleva segundos. La huella de memoria es de cientos de MiB antes de que tu carga de trabajo comience. Para una solicitud web que dura 40ms, gastarías 40 veces eso arrancando la máquina.

Así que estás atrapado entre:

• Contenedores: arranque de 50ms, 5 MiB de sobrecarga, superficie de ataque del kernel compartido.
• VMs: arranque de 5+ segundos, 300+ MiB de sobrecarga, aisladas por hardware.

Todos los que ejecutan código multiinquilino no confiable (AWS, y prácticamente todos los proveedores de sandboxes de IA existentes) necesitan ambos lados de esa compensación a la vez.

Las microVMs

Un VMM (Monitor de Máquina Virtual) es el proceso en espacio de usuario que impulsa el hipervisor: configura la memoria del invitado, conecta dispositivos virtuales y le dice a KVM que comience a ejecutar el código del invitado.

Una microVM es un VMM con el PC de 1998 eliminado: sin BIOS, sin bus PCI, sin VGA, sin USB, sin ACPI (ninguno del hardware heredado por el que arranca un escritorio real, y nada de eso relevante para una llamada de función de 40ms). Lo que queda: KVM, una consola serie y un puñado de dispositivos virtio (red, bloque, vsock).

virtio es la interfaz de dispositivo estándar "Sé que estoy ejecutándome en una VM". El invitado coopera con el hipervisor a través de NICs y discos virtuales ligeros (virtio-net, virtio-block) en lugar de fingir que maneja una tarjeta Intel e1000 real o una controladora IDE. Esa cooperación, más todo el hardware heredado faltante, es la razón más importante por la que las microVMs arrancan rápido.

El resultado:

• ~125ms de arranque desde el lanzamiento del VMM hasta que el espacio de usuario del invitado ejecuta init.
• <5 MiB de sobrecarga de memoria del VMM por VM (la memoria de contabilidad que el host paga por VM, antes de que la carga de trabajo del invitado asigna algo para sí mismo).
• 150 VMs/segundo de creación en un solo host.
• ~2–8% de impacto en el rendimiento en tiempo de ejecución en comparación con metal desnudo.

El mismo aislamiento a nivel de hardware que una VM completa con la misma densidad de magnitud que un contenedor.

Firecracker es el VMM, el proceso que realmente habla con /dev/kvm y arranca la microVM. El resto de esta publicación es esa pila de principio a fin.

Firecracker

En noviembre de 2018, AWS lanzó Firecracker como código abierto en re:Invent. Ya estaba ejecutando Lambda en producción, lo que hace que tu import pandas se inicie en frío lo suficientemente rápido como para facturar por milisegundo. En 2020, el equipo publicó la arquitectura en NSDI '20.

La arquitectura

Bifurcado de crosvm de Google, reescrito en Rust, con más de la mitad del código eliminado. Cada proceso de Firecracker es una microVM, con exactamente tres tipos de hilos (documentados en docs/design.md):

• El hilo API es la mesa de pedidos. Un servidor REST vinculado a un socket Unix (un socket solo local que vive como un archivo en el disco, no un puerto TCP). Acepta configuración antes del arranque y acciones limitadas después.
• El hilo VMM es el taller de hardware. Finge ser cada dispositivo que el invitado puede ver. Cuando el invitado toca lo que cree que es un registro de NIC, la CPU pausa al invitado, el VMM maneja el toque ("el invitado pateó la cola de TX, drenarla") y reanuda. El mecanismo: el invitado lee/escribe direcciones mágicas; la CPU las atrapa hacia el host.[^mmio]
• Los hilos vCPU son los corredores. Uno por CPU invitado, cada uno en un bucle cerrado: pedirle a KVM que ejecute al invitado hasta que algo interesante suceda (toque de dispositivo, interrupción, detención), manejarlo, repetir.

Se comunican entre sí a través de canales de Rust (colas de mensajes sin bloqueo dentro del proceso). El invitado ve exactamente cuatro dispositivos.

Los cuatro dispositivos

• virtio-net es la NIC de la VM, sin emulación de 1998. El invitado escribe paquetes en una virtqueue (un búfer circular en memoria compartida); el VMM los drena a través de un dispositivo TAP del lado del host (una interfaz Ethernet virtual que el kernel expone como un archivo), impulsado por io_uring o epoll para que el hilo VMM no se bloquee.
• virtio-block es el disco de la VM, solo IO de archivos en el host. El invitado pone solicitudes de sector en una virtqueue; el VMM emite simples pread/pwrite contra un archivo del host. Sin IDE, sin AHCI, sin SCSI.
• virtio-vsock es el intercomunicador de la VM con el host. Se direcciona por una tupla (ID de contexto, puerto) en lugar de un par IP/puerto, para que el agente invitado pueda contactar a casa (registros, pings de salud, metadatos de instantáneas) sin IP de invitado y sin nada en el cable que pueda ser falsificado.
• UART serie 8250 es la consola de arranque. Un pequeño chip serie heredado emulado en una dirección fija. Se usa para registros de arranque temprano y volcados de fallos antes de que virtio se active. Barato, universal, nunca desaparecerá.

Arranque de una microVM, de principio a fin

La API es todo el plano de control: el canal de configuración, mantenido deliberadamente separado del plano de datos (los hilos vCPU que realmente ejecutan el código invitado). Inicias el binario apuntando a un socket Unix:

Luego pones configuración en él:

Cuatro llamadas HTTP. Eso es todo el plano de control.

La cebolla de seguridad

Un solo límite de KVM ya es fuerte. Firecracker envuelve dos capas más alrededor de él.

El jailer es un constructor de sandboxes. Su único trabajo es encerrar al VMM antes de que se ejecute. Crea un chroot (una característica de Linux que bloquea un proceso a un solo subárbol de directorios como si ese directorio fuera la raíz del sistema de archivos; el proceso literalmente no puede nombrar nada arriba), cae en un nuevo espacio de nombres PID para que no pueda ver los otros procesos del host, cambia a un uid/gid no privilegiado, aplica límites de CPU/memoria de cgroup, y solo entonces ejecuta el binario de Firecracker dentro de esa jaula:

Ahora el proceso VMM no tiene sistema de archivos excepto un chroot dedicado, ninguna vista de otros procesos en el host y ninguna capacidad de root. Si un escape de invitado a host llega a través de virtio o KVM, el atacante aterriza en ese chroot con límites de cgroup.

Seccomp es una lista blanca de llamadas al sistema por hilo. Cualquier cosa que no esté en la lista es asesinada (o devuelve EPERM) antes de que llegue al manejador de llamadas del kernel. Firecracker tiene tres niveles:

1. Nivel 0: desactivado. No usar en producción.
2. Nivel 1: lista blanca por número de llamada al sistema.
3. Nivel 2: también restringe los valores de los argumentos (ej. ioctl está bien, pero solo con KVM_RUN como comando). Predeterminado y recomendado.

Cada hilo obtiene la superficie mínima posible: el mínimo posible: el hilo API no necesita ioctl(KVM_RUN); los hilos vCPU no necesitan socket(). Una vista simplificada de cómo se ve una regla:

Cada capa tiene que fallar independientemente para que un atacante llegue al host.

Instantáneas: el truco detrás de Lambda SnapStart

Toma una instantánea de una microVM en ejecución. Restáurala en milisegundos, en un host diferente, en un nuevo proceso VMM. Salta el arranque del kernel, salta el init, salta el calentamiento JIT.

Congelas la VM en ejecución y vuelcas el estado de la memoria + los dispositivos al disco:

Una instantánea captura el estado posterior al calentamiento, por lo que la VM restaurada se despierta en medio de su vida, no al principio.

Esto es exactamente lo que hace AWS Lambda SnapStart: inicializar un Java Lambda una vez, tomar una instantánea de la microVM y restaurar esa instantánea en cada inicio en frío posterior (anuncio). Los inicios en frío de JVM pasan de 8+ segundos a menos de un segundo.

Cómo encajan

gVisor es un diseño diferente: un kernel en espacio de usuario en Go, una reimplementación de la interfaz de llamadas al sistema de Linux que se ejecuta como un proceso normal. Las llamadas al sistema del invitado golpean a gVisor en lugar del kernel del host, y gVisor decide qué (si algo) reenviar. Más rápido de iniciar que una microVM, 10–30% de sobrecarga de llamadas al sistema en la ruta caliente, y un límite de confianza diferente.

Firecracker está en la caja "mi propio kernel, pero sin BIOS PCI": aislamiento de hardware, modelo de dispositivo diminuto y arranque en milisegundos.

Elige tu herramienta:

Quién usa esto

Es casi más rápido enumerar las plataformas serverless que no están sobre microVMs.

Firecracker en producción:

• producción:

• AWS Lambda y AWS Fargate: el caso de uso original. Cada invocación de Lambda aterriza en una microVM de Firecracker; las tareas de Fargate son VMs de Firecracker con un runtime de contenedor delgado dentro.
• [Fly.io Machines](https://fly.io/docs/machines/): cada máquina fly run es una microVM de Firecracker, distribuida globalmente, con inicios en frío de menos de un segundo y discos persistentes.
• Casi todos los sandboxes de ejecución de código para agentes de IA que has usado en los últimos dieciocho meses viven en una microVM de Firecracker.

La forma de una API de sandbox es más o menos la misma en todos los proveedores en este punto:

En aproximadamente cuatro líneas de código: una microVM de Firecracker arranca, un kernel se inicializa, un proceso agente dentro del invitado recibe tu comando a través de vsock, lo ejecuta, transmite los resultados de vuelta, y la VM muere.

La era de los agentes: por qué importa ahora

Hace un año, "¿qué es un sandbox de IA?" era una pregunta de nicho. Si un LLM generaba código, probablemente no era 100% seguro ejecutarlo en cualquier máquina, así que lo ejecutabas en un sandbox efímero.

Hoy, cada producto serio de IA incluye un agente. Sus sandboxes mejoraron, pero la forma de los agentes cambió, y las respuestas antiguas no encajan en la nueva forma.

Agentes en proceso vs agentes a nivel de host

La primera ronda de agentes de IA vivía dentro de tu aplicación. Importabas una biblioteca, configurabas un bucle y lo ejecutabas en tu backend existente:

Cada llamada era un viaje de ida y vuelta HTTP a un modelo. Cada llamada de herramienta era una función en tu propio proceso. El "sandbox" era tu propio servidor. Este es el mundo de Vercel AI SDK, LangChain, OpenAI Agents SDK. Funciona muy bien y sigue impulsando una gran parte de los agentes de producción hoy.

La segunda ronda es diferente. Claude Code, Codex y OpenCode son agentes a nivel de host: binarios que toman el control de una máquina, no bibliotecas que viven dentro de la tuya. Esperan un shell real, un gestor de paquetes y un disco escribible. Cuando le das a Claude Code una tarea, ejecuta algo como esto:

Eso es un shell/bash. Necesita un sistema de archivos real, un fork/exec real, un gestor de paquetes, un disco en el que puedas escribir, una red a la que puedas llegar. Nada de eso es expresable como un esquema de herramienta de chat-completion, y nada de eso es seguro de ejecutar en un contenedor de kernel compartido junto a otros inquilinos.

Los laboratorios están entrenando sus modelos directamente en estos arneses (el andamiaje alrededor del modelo): el shell, el editor de archivos, el ejecutor de pruebas, el bucle del agente mismo. Eso significa que la brecha entre "modelo + arnés en el que fue entrenado" y "modelo + andamio casero" se está haciendo más grande cada trimestre.

Una máquina Linux completa por agente, ejecutando código no confiable que el agente acaba de inventar, es exactamente la carga de trabajo para la que se construyó Firecracker. La convergencia anterior no fue un accidente.

Estamos empezando a ver más experimentación con agentes que separan el cómputo y el arnés. Managed Agents de Anthropic es un ejemplo de esto, donde el arnés del agente se ejecuta junto al sandbox, no dentro de él.

Algunas empresas incluso están construyendo sistemas de archivos alojados completos (como Archil y Mesa), para dar a los agentes mejor búsqueda y almacenamiento.

A medida que los agentes mejoren y cambien con el tiempo, habrá muchas más ofertas de infra interesantes, construidas sobre Firecracker.

Por lo que realmente pagas a las plataformas de infra de agentes

Los sandboxes genéricos de "ejecutar código arbitrario" son ahora un producto básico. La infraestructura es completamente de código abierto. La capa de microVM es Firecracker o Cloud Hypervisor, disponible bajo Apache 2.0. La conversión de contenedor a rootfs es un script de Go de 200 líneas. Ingenieros talentosos pueden montar una plataforma de sandbox funcional en un fin de semana.

Pagas por lo que está conectado a la VM. La microVM desnuda es el precio de entrada.

La superficie de producto interesante:

• La observabilidad es el producto, no una ayuda de depuración. Todo lo que el agente hace (stdout, llamadas al sistema, escrituras de archivos, solicitudes de red) fluye a través de un solo socket a un recolector del lado del host. Los creadores de agentes necesitan reproducción completa de la sesión y los artefactos por acción para crear los mejores productos.
• Los secretos se negocian en el cable, nunca se entregan al invitado. El invitado solo ve variables de entorno marcadores de posición; echo $SECRET dentro del sandbox devuelve el marcador de posición. Un proxy de salida del lado del host (cada paquete saliente tiene que cruzarlo) sustituye la credencial real en el TAP del lado del host (el extremo propiedad del kernel de la NIC virtual de la VM, que el invitado no puede ver ni direccionar), contra una lista blanca explícita, con un registro de auditoría por sesión. El agente puede estar ejecutando código arbitrario que generó hace cinco segundos y aún así no puede exfiltrar una credencial que nunca tuvo.
• La identidad se firma en el host, no dentro del agente. Las solicitudes salientes pueden llevar una identidad criptográfica por sesión (incluyendo firmas Web Bot Auth, construidas sobre HTTP Message Signatures + Ed25519) acuñada por el host antes de que el paquete salga del puente. La clave de firma nunca entra en la microVM.
• El otro cómputo se agrupa en la misma microVM que el runtime. Browserbase empareja cada runtime de agente 1:1 con un navegador en el mismo host, a menudo la misma microVM. La distancia física entre el proceso del agente y Chromium es efectivamente cero: los comandos CDP (el Protocolo de Chrome DevTools Protocol, el formato de cable JSON sobre WebSocket usado para controlar Chrome programáticamente) van sobre un socket Unix, no a través de una red de servicios, por lo que la latencia de acción es de un solo dígito de milisegundos. Los frames de screencast no tienen que cruzar el internet público para llegar a la reproducción de la sesión.

Y no puedes simplemente unir todo esto limpiamente sobre Docker. Las costuras no están ahí. Nuestra apuesta es que el mercado de runtimes de agentes no se ganará con cómputo en bruto, sino con la mejor observabilidad, secretos, identidad, asociaciones y el cómputo colocado en un solo producto.

Alternativas de runtime que vale la pena observar

• [Bubblewrap](https://github.com/containers/bubblewrap): sandboxing con espacios de usuario no privilegiados. Un usuario no root puede iniciar un sandbox sin sudo, usando los mismos primitivos del kernel que Flatpak usa para confinar aplicaciones de escritorio. Más ligero que una VM, sigue compartiendo el kernel del host, por lo que no es un sustituto de las microVMs contra código verdaderamente no confiable. Pero es una excelente capa de aislamiento anidado para ejecutar dentro de una microVM, o una buena opción para código más o menos confiable en tu propio host.
• [V8 isolates](https://blog.cloudflare.com/cloud-computing-without-containers/): el modelo de Cloudflare Workers. Cada isolate es un contexto de ejecución JS separado con su propio heap, compartiendo un solo proceso V8 con potencialmente miles de otros inquilinos. El inicio es de ~5ms, dos órdenes de magnitud más rápido que una microVM. El límite de confianza es el propio sandbox de V8; históricamente se ha mantenido bien, pero es una línea mucho más delgada que la de un hipervisor. El otro inconveniente: solo obtienes semánticas al estilo de Node. Sin fork, sin exec, sin módulos nativos, sistemas de archivos simulados. Devastador para código de agente JS puro; inútil si necesitas pip install numpy.
• [gVisor](https://gvisor.dev/): el kernel en espacio de usuario de Google en Go. Aislamiento fuerte sin virtualización anidada (una VM invitada ejecutándose dentro de otra VM, que la mayoría de los proveedores de nube deshabilitan por defecto; gVisor no la necesita, por lo que funciona en GKE de fábrica). Paga ~10–30% en cargas de trabajo intensivas en llamadas al sistema. Un término medio sólido cuando la virtualización de hardware no está disponible.
• Sandboxes WASM (wasmtime, wasmer): deterministas, pequeños, rápidos, pero el ecosistema es poco profundo. WASI (la API de llamadas al sistema estándar para WASM) está madurando. Aún no es un objetivo directo para "ejecutar este binario arbitrario de Python/Node".

Si estás construyendo para código no confiable de propósito general: Firecracker (o Cloud Hypervisor, un VMM/diseño virtio similar). Si estás construyendo para cargas de trabajo JS conocidas: V8 isolates. Todo lo demás es una respuesta especializada a una pregunta especializada.

El panorama general

Firecracker tomó una de las ideas más antiguas de la computación, una máquina virtual, y eliminó lo suficiente para hacerla barata. Apuesta a que el aislamiento forzado por hardware vale la pena si puedes hacerlo lo suficientemente rápido.

Esa apuesta siempre iba a dar frutos para serverless. Lo que ha cambiado es que la carga de trabajo de "código multiinquilino no confiable" ha pasado de "una función web que no quiero poner en sandbox" a "un agente generando comandos arbitrarios que podrían tocar producción." El perímetro se movió y la tolerancia para escapes del kernel compartido pasó de "riesgo aceptable" a "no se puede lanzar".

Y lo hizo. Es un binario de Rust, de 50.000 líneas, que habla con /dev/kvm.

Los contenedores empaquetan software. Las microVMs lo aíslan. La ingeniería interesante de la próxima década es todo lo que envuelves alrededor de la caja.

→ Kyle

Esta publicación del blog tiene componentes interactivos y animaciones (que no se muestran en los artículos de X. Si quieres ver esa versión, está aquí: https://www.browserbase.com/blog/what-is-firecracker.