Firecracker: microVMs para servicios multi-tenant

Actualizado: 2026-05-03

Firecracker llegó con AWS Lambda en 2018 y desde entonces ha sido la capa de aislamiento real detrás de millones de invocaciones serverless y de los contenedores Fargate. Durante años fue un proyecto casi exclusivo de AWS. En 2025 eso ha cambiado: hay un número creciente de plataformas de ejecución de código de terceros que lo están adoptando fuera de AWS.

Puntos clave

• Firecracker es un VMM escrito en Rust, basado en KVM, con objetivo muy acotado: arrancar microVMs en menos de 125 ms con menos de 5 MB de overhead por VM.
• No reemplaza a Docker: reemplaza al runtime del contenedor cuando se necesita aislamiento más fuerte que el que ofrece el kernel compartido.
• Tres factores impulsan la adopción: proliferación de plataformas de ejecución de código no confiable, presión de seguridad en plataformas multi-tenant y madurez del ecosistema (Kata Containers, Fly.io, Koyeb).
• Frente a gVisor: Firecracker ofrece mejor rendimiento I/O y superficie de ataque KVM, a cambio de arranque ligeramente más lento y mayor overhead de memoria.
• Las tres asperezas que siguen son networking (tap devices, bridges), almacenamiento (conversión rootfs) y observabilidad del VMM.

Qué es y qué no es

Firecracker es un monitor de máquina virtual (VMM) escrito en Rust, basado en KVM, con un objetivo muy acotado: arrancar microVMs en menos de 125 milisegundos, consumir menos de 5 MB de memoria de overhead por VM y exponer una API de control minimalista. No es un hipervisor de propósito general como QEMU; deliberadamente omite dispositivos heredados (USB, gráficos, audio) que no tienen sentido para cargas serverless.

La posición arquitectónica importante es: Firecracker no reemplaza a Docker. Reemplaza al runtime del contenedor (runc, crun) cuando se necesita aislamiento más fuerte que el que ofrece el kernel compartido. El código de aplicación sigue empaquetándose como imagen OCI; lo que cambia es que, en lugar de ejecutarse en un namespace del kernel del host, se ejecuta dentro de una microVM con su propio kernel Linux minimalista.

Por qué está resurgiendo el interés

Tres factores confluyen para explicar la adopción que se ve en 2025:

1. Proliferación de plataformas de ejecución de código de usuario no confiable. En el contexto de los agentes LLM, cada vez más productos ejecutan código generado por un modelo en un entorno aislado del servicio principal. Firecracker da ese aislamiento con arranque rápido suficiente para interactividad humana (centenares de milisegundos, no segundos). Relacionado directamente con la defensa frente a prompt injection: cuando el agente ejecuta código, el aislamiento de la microVM es la última barrera.
2. Presión de seguridad sobre plataformas multi-tenant de funciones. Las fugas de contenedor documentadas en los últimos años han hecho que los equipos de seguridad de empresas medianas descarten soluciones basadas solo en namespaces. Un CVE en runc o containerd puede comprometer al host; un CVE similar en una microVM queda acotado dentro del invitado.
3. Madurez del ecosistema. Firecracker ya tiene integraciones estables con Kata Containers (compatible con la interfaz CRI de Kubernetes), con Fly.io como plataforma pública, con Koyeb y con varios proveedores de ejecución de código sandbox para agentes. Hace dos años haber elegido Firecracker significaba construir toda la plomería; ahora hay opciones listas.

Frente a gVisor: trade-off concreto

La alternativa natural en el espacio de aislamiento reforzado es gVisor, el sandbox de Google basado en intercepción de syscalls. Los dos resuelven el mismo problema pero con mecanismos distintos:

gVisor: – Arranque rápido, comparable a un contenedor. – Overhead de memoria muy bajo. – Transparente para el invitado. – El rendimiento de cargas intensivas en I/O sufre. – La superficie de ataque es el propio motor gVisor; un fallo ahí compromete el host.

Firecracker: – Arranque ligeramente más lento que gVisor pero aún rápido. – Overhead de memoria ligeramente mayor. – El invitado necesita un kernel propio. – Rendimiento de I/O cercano al nativo. – Superficie de ataque es KVM, mucho más auditada que gVisor.

Mi regla práctica: si la carga es de corta duración (milisegundos a segundos) y tolera el overhead de syscalls, gVisor es más simple operativamente. Si la carga es más larga o intensiva en I/O (ejecución de código de agentes, procesamiento de archivos, ML inference), Firecracker rinde mejor y ofrece un aislamiento que la mayoría de auditores aceptan sin discusión.

Asperezas que siguen

Firecracker en 2025 es maduro pero no libre de fricción. Hay tres áreas que requieren atención:

1. Networking. La plomería de red requiere tap devices, bridges y típicamente un daemon que gestiona la asignación de direcciones y rutas. Herramientas como firecracker-containerd y el plugin CNI de firecracker alivian parte del trabajo, pero sigue siendo más complejo que el networking de Docker estándar.
2. Almacenamiento. Firecracker usa imágenes de disco raw o qcow2 como volúmenes. Preparar una imagen arrancable desde una imagen OCI no es automático; hay que convertir el rootfs y generar un kernel minimalista.
3. Observabilidad. Dentro de la microVM el invitado es un sistema Linux normal. Pero la observabilidad del propio Firecracker (VMs activas, consumo de memoria del VMM, tiempo de arranque por VM) requiere scrapear la API de control o integrar el exporter que expone métricas. Sin eso, diagnosticar un incidente en producción es difícil. Misma disciplina que aplicamos en profiling continuo con eBPF.

Mi lectura

Firecracker ha pasado de ser una curiosidad interna de AWS a una pieza real del stack multi-tenant. Para el caso concreto de ejecutar código de usuario no confiable (agentes LLM, plataformas de funciones, entornos sandbox de IDE en la nube) la elección ya no es obvia hacia containers; la elección es entre gVisor y Firecracker, con los containers puros descartados por el equipo de seguridad.

Lo que me parece notable es la ventana de oportunidad para plataformas intermedias. Hace tres años, solo AWS podía permitirse el coste de operar Firecracker a escala. Hoy, con herramientas como Kata Containers, Fly Machines o firecracker-containerd, un equipo pequeño puede montar una plataforma multi-tenant con aislamiento serio en semanas. Eso cambia las barreras de entrada para productos que antes necesitaban un hyperscaler detrás.

Mi recomendación a quien está evaluando: si el caso es ejecutar código que tu equipo no controla (usuarios finales, agentes, plugins), Firecracker merece una prueba de concepto esta semana. Si el caso es aislar servicios que tu equipo sí controla, quédate con containers estándar y resiste la tentación de complicar la pila por miedos que no se materializan en tu modelo de amenazas.