zeroboot

Sandboxes de VM sub-milisegundo para agentes de IA mediante fork 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))"}'

Evaluaciones de rendimiento

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

Cómo funciona

  Snapshot de Firecracker ──► mmap(MAP_PRIVATE) ──► VM KVM + estado de CPU restaurado
                              (copy-on-write)         (~0,8ms)

1. Plantilla (única vez): Firecracker inicia una VM, precarga tu runtime y guarda una snapshot de memoria + estado de CPU
2. Fork (~0,8ms): Crea una nueva VM KVM, mapea la memoria de la snapshot como CoW, restaura todo el estado de la CPU
3. Aislamiento: Cada fork es una VM KVM separada con aislamiento de memoria reforzado 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

Estado

Prototipo funcional. La primitiva de fork, las evaluaciones y la API son reales, pero aún no están endurecidas para producción. Abre un issue si estás interesado.

Autogestionado o administrado

Zeroboot es código abierto. Hospédalo tú mismo en cualquier máquina Linux con KVM, o usa la API administrada:

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))"}'

Construyendo el servicio administrado para equipos que no quieren gestionar su propia infraestructura. Regístrate para acceso anticipado: https://tally.so/r/aQGkpb

Limitaciones conocidas

• Los forks comparten el estado del CSPRNG de la snapshot. La entropía del kernel se resemilla mediante RNDADDENTROPY, pero los PRNGs del espacio de usuario (numpy, OpenSSL) necesitan resiembra explícita por fork. Consulta la guía de Firecracker.
• Una sola vCPU por fork. Multi-vCPU es factible arquitectónicamente pero no está implementado.
• Sin networking dentro de los forks. Los sandboxes se comunican únicamente mediante E/S serie.
• Las actualizaciones de plantillas requieren una nueva snapshot completa (~15s). No hay parches incrementales.

Licencia

Apache-2.0