zeroboot

Sandboxes de VM sub-milisegundo para agentes de IA mediante bifurcación copy-on-write

---

Pruébalo

curl -X POST https://api.zeroboot.dev/v1/exec \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer zb_demo_hn2026' \
  -d '{"code":"import numpy as np; print(np.random.rand(3))"}'

Benchmarks

Métrica	Zeroboot	E2B	microsandbox	Daytona
Latencia de creación p50	0,79ms	~150ms	~200ms	~27ms
Latencia de creación p99	1,74ms	~300ms	~400ms	~90ms
Memoria por sandbox	~265KB	~128MB	~50MB	~50MB
Fork + exec (Python)	~8ms	-	-	-
1000 forks concurrentes	815ms	-	-	-

Cada sandbox es una máquina virtual KVM real con aislamiento de memoria impuesto por hardware.

Cómo funciona

  Firecracker snapshot ──► mmap(MAP_PRIVATE) ──► KVM VM + restored CPU state
                              (copy-on-write)         (~0.8ms)

1. Plantilla (una sola vez): Firecracker arranca una VM, precarga tu runtime y toma una instantánea del estado de memoria + CPU
2. Fork (~0.8ms): Crea una nueva VM de KVM, mapea la memoria de la instantánea como CoW, restaura todo el estado de la CPU
3. Aislamiento: Cada fork es una VM de KVM separada con aislamiento de memoria impuesto por hardware

SDKs

Python — sdk/python

from zeroboot import Sandbox
sb = Sandbox("zb_live_your_key")
result = sb.run("print(1 + 1)")

TypeScript — sdk/node

import { Sandbox } from "@zeroboot/sdk";
const result = await new Sandbox("zb_live_your_key").run("console.log(1+1)");

Documentación

• Referencia de la API
• Guía de despliegue
• Arquitectura

Autor

Zeroboot fue creado en marzo de 2026 y está mantenido por Adam Miribyan (@adammiribyan). Sitio del proyecto: zeroboot.dev.

Si usas zeroboot en investigación, por favor cítalo; consulta CITATION.cff o usa el botón "Cite this repository".

Citado por

• DeltaBox: Scaling Stateful AI Agents with Millisecond-Level Sandbox Checkpoint/Rollback, arXiv:2605.22781 (mayo de 2026).
• Memory Compression for High-Fanout Agent Sandboxes (AgentZip), arXiv:2609.11294 (septiembre de 2026).

Si tu artículo o proyecto usa zeroboot, abre un issue o un pull request para añadirlo aquí.

Estado

Prototipo funcional. La primitiva de fork, los benchmarks y la API son reales, pero aún no están endurecidos para producción. Abre un issue si te interesa.

Autoalojado o gestionado

Zeroboot es de código abierto. Autoalójalo en cualquier máquina Linux con KVM, o usa la API gestionada:

curl -X POST https://api.zeroboot.dev/v1/exec \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer zb_demo_hn2026' \
  -d '{"code":"import numpy as np; print(np.random.rand(3))"}'

Estamos construyendo el servicio gestionado para equipos que no quieren ejecutar su propia infraestructura. Regístrate para el acceso anticipado: https://tally.so/r/aQGkpb

Limitaciones conocidas

• Los forks comparten el estado del CSPRNG de la instantánea. La entropía del kernel se vuelve a sembrar mediante RNDADDENTROPY, pero los PRNG de espacio de usuario (numpy, OpenSSL) necesitan un reseeding explícito por fork. Consulta la guía de Firecracker.
• Una sola vCPU por fork. Multi-vCPU es arquitectónicamente posible pero no está implementado.
• Sin red dentro de los forks. Los sandboxes se comunican únicamente mediante E/S serie.
• Las actualizaciones de plantilla requieren una nueva instantánea completa (~15s). Sin parcheo incremental.

Licencia

Apache-2.0