¿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? ¿Cómo? Alrededor de 50,000 líneas de Rust llamadas Firecracker, que existen 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 laptop son tres características del kernel de Linux en un abrigo:

• Los namespaces son vendas para los ojos. Un proceso dentro de uno obtiene una vista privada del sistema: su propia lista de PID, 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 CPU, memoria, IO de disco IO y ancho de banda de red puede consumir un árbol de procesos.
• 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 otorgar solo los que necesitas. seccomp es un filtro por proceso que decide qué syscalls (la única API del espacio de usuario hacia el kernel) el proceso puede hacer.

Puedes probarlo tú mismo sin tener Docker instalado:

Todo lo demás que hace Docker (capas de imágenes, registros, DNS) es orquestación encima.

Toda esa protección pasa por un solo kernel Linux, alrededor de 30 millones de líneas de código que exponen más de 400 syscalls. Cada contenedor en el host llama a ese mismo kernel. Un error en cualquiera de esas syscalls y se acabó el juego para todos los inquilinos 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 CPUs modernas tienen un "modo invitado" que ejecuta 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 de hardware (vmx en Intel, svm en AMD):

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

Así que estás atrapado entre:

• Contenedores: arranque de 50 ms, 5 MiB de sobrecarga, superficie de ataque de 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 básicamente todos los proveedores de sandboxes de IA existentes) necesitan ambos lados de esa compensación a la vez.

Llegan 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 código del invitado.

Una microVM es un VMM con la PC de 1998 eliminada: 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 40 ms). Lo que queda: KVM, una consola serie y un puñado de dispositivos virtio (net, block, 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 livianos (virtio-net, virtio-block) en lugar de fingir que maneja una tarjeta Intel e1000 real o un controlador IDE. Esa cooperación, más todo el hardware heredado faltante arriba, es la razón más importante por la que las microVMs arrancan rápido.

El resultado:

• ~125 ms 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 el host por VM, antes de que la carga de trabajo del invitado asigne algo para sí misma).
• 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.

Mismo nivel de aislamiento por hardware que una VM completa con el mismo orden de magnitud de densidad 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 extremo a extremo.

Firecracker

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

La arquitectura

Bifurante Fork de crosvm, 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):

• Hilo API es la mesa de pedidos. Un servidor REST vinculado a un socket Unix (un socket solo local que vive como archivo en disco, no un puerto TCP). Acepta configuración antes del arranque y acciones limitadas después.
• Hilo VMM es el piso de fábrica 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]
• Hilos vCPU son los corredores. Uno por CPU invitada, cada uno en un bucle apretado: 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 de bloqueo entre hilos). 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 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 pread/pwrite simples 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 un par (context-id, port) en lugar de un par IP/puerto, para que el agente invitado pueda llamar a casa (logs, pings de salud, metadatos de instantánea) sin IP de invitado y nada en el cable para falsificar.
• 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 pánico antes de que virtio se active. Barato, universal, nunca desaparecerá.

Arranque de una microVM, de extremo a extremo

La API es todo el plano de control: el canal de configuración, mantenido deliberadamente separado deliberadamente del plano de datos (los hilos vCPU que realmente ejecutan código del 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.

El jailer es un constructor de sandbox. 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 por encima de él), 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 del cgroup, y solo entonces ejecuta el binario de Firecracker dentro de esa cárcel:

Ahora el proceso VMM no tiene sistema de archivos excepto un chroot dedicado, ninguna vista de otros procesos en el host y sin capacidades 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 syscalls por hilo. Cualquier cosa que no esté en la lista es matada (o devuelve EPERM) antes de que llegue al manejador de syscalls del kernel. Firecracker envía tres niveles:

1. Nivel 0: apagado. No usar en producción.
2. Nivel 1: lista blanca por número de syscall.
3. Nivel 2: también restringir valores de argumentos (ej. ioctl está bien, pero solo con KVM_RUN como comando). Por defecto y recomendado.

Cada hilo obtiene la superficie mínima 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 debe 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 proceso VMM nuevo. Salta el arranque del kernel, salta init, salta el calentamiento JIT.

Congelas la VM en ejecución y volcar memoria + estado del dispositivo a disco:

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

Esto es exactamente lo que hace AWS Lambda SnapStart: inicializar una Java Lambda una vez, instantánea la microVM y restaurar esa instantánea en cada arranque en frío posterior (anuncio). Los arranques en frío de JVM pasan repentinamente 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 syscall de Linux que se ejecuta como un proceso normal. Las syscalls del invitado golpean gVisor en lugar del kernel anfitrión, y gVisor decide qué (si algo) reenviar aguas abajo. Más rápido de arrancar que una microVM, 10–30% de sobrecarga de syscall en la ruta caliente, y un límite de confianza diferente.

Firecracker se sienta en la caja "mi propio kernel, pero sin PCI BIOS": aislamiento por hardware, modelo de dispositivo pequeño y arranque en milisegundos.

Elige tu herramienta:

Quién usa esto

Es casi más rápido listar las plataformas serverless que no se sientan sobre microVMs.

Firecracker en 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 tiempo de ejecución 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 arranques en frío de menos de un segundo y discos persistentes.
• Casi todos los sandbox de ejecución de código de 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 alrededor de 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é todo esto 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 para ejecutar en cualquier máquina, así que lo ejecutarías en un sandbox efímero.

Hoy cada producto serio de IA envía un agente. Sus sandboxes también mejoraron, pero la forma de los agentes cambió, y las viejas respuestas de tiempo de ejecución 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 librería, conectabas 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 todavía envía 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 librerías 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 este tipo de cosas:

Eso es un shell/bash. Necesita un sistema de archivos real, un fork/exec real, un gestor de paquetes, 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 para 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 + andamiaje 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 fue construido Firecracker. La convergencia anterior no fue un accidente.

Estamos empezando a ver más experimentación con agentes que separan la computación 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 almacen.

A medida que los agentes mejoran y cambian con el tiempo, habrá muchas más ofertas de infraestructura interesantes, construidas sobre Firecracker.

Lo que realmente estás pagando a las plataformas de infraestructura de agentes

Los sandboxes genéricos de "ejecutar código arbitrario" son un ahora. La infraestructura está completamente en 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 Go de 200 líneas. Ingenieros talentosos pueden levantar una plataforma de sandbox funcional en un fin de semana.

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

La superficie de producto interesante:

• Observabilidad es el producto, no una ayuda de depuración. Todo lo que hace el agente (stdout, syscalls, escrituras de archivos, solicitudes de red) fluye a través de un solo socket a un recolector del lado del host. Los constructores de agentes necesitan reproducción completa de la sesión y los artefactos por acción para crear los mejores productos.
• Secretos se negocian en el cable, nunca se entregan al invitado. El invitado solo ve variables de entorno marcadores; echo $SECRET dentro del sandbox devuelve el marcador. Un proxy de salida del lado del host (cada paquete saliente debe 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 rastro 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.
• Identidad se firma en el host, no dentro del agente. Las solicitudes salientes pueden llevar una identidad criptográfica por sesión criptográfica por sesión (incluyendo firmas de 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.
• La otra computación se agrupa en la misma microVM que el tiempo de ejecución. Browserbase empareja cada tiempo de ejecución del 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 Herramientas de Chrome, 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 milisegundo. Los fotogramas de screencast no tienen que cruzar el internet público para llegar a la reproducción de 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 tiempo de ejecución de agentes no se ganará con computación cruda, sino con la mejor observabilidad, secretos, identidad, asociaciones y la computación colocalizada colapsada en una sola superficie de producto.

Alternativas de tiempo de ejecución que vale la pena observar

• [Bubblewrap](https://github.com/containers/bubblewrap): sandboxing de espacio de nombres de usuario no privilegiado. Un usuario no root puede levantar un sandbox sin sudo, usando los mismos primitivos del kernel que Flatpak usa para confinar aplicaciones de escritorio. Más ligero que una VM, aún comparte el kernel del host, por lo que no es un sustituto de las microVMs contra código verdaderamente no confiable. Pero es una gran 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.
• [Aislamientos V8](https://blog.cloudflare.com/cloud-computing-without-containers/): el modelo de Cloudflare Workers. Cada aislamiento es un contexto de ejecución de JS separado con su propio heap, compartiendo un solo proceso V8 con potencialmente miles de otros inquilinos. El arranque es ~5 ms, 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. La otra pega: solo obtienes semánticas al estilo 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 lo necesita, así que funciona en GKE de fábrica). Paga ~10–30% en cargas de trabajo intensivas en syscall. 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 syscall estándar para WASM) está madurando. No es un objetivo directo para "ejecutar este binario arbitrario de Python/Node" todavía.

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

El panorama general

Firecracker tomó una de las ideas más antiguas en 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 crecido de "una función web que no quiero poner en sandbox" a "un agente que genera comandos arbitrarios que podrían tocar producción". El perímetro se movió y la tolerancia a escapes de kernel compartido pasó de "riesgo aceptable" a "no se puede enviar".

Y lo hizo. Es un binario 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 de 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.