zeroboot

Sandbox VM sub-milliseconde pour agents IA via fork copy-on-write

---

Essayez-le

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étrique	Zeroboot	E2B	microsandbox	Daytona
Latence de spawn p50	0.79ms	~150ms	~200ms	~27ms
Latence de spawn p99	1.74ms	~300ms	~400ms	~90ms
Mémoire par sandbox	~265KB	~128MB	~50MB	~50MB
Fork + exec (Python)	~8ms	-	-	-
1000 forks simultanés	815ms	-	-	-

Chaque sandbox est une vraie machine virtuelle KVM avec isolation mémoire assurée par le matériel.

Comment ça marche

  Snapshot Firecracker ──► mmap(MAP_PRIVATE) ──► VM KVM + état CPU restauré
                              (copy-on-write)         (~0.8ms)

1. Modèle (une fois) : Firecracker démarre une VM, précharge votre runtime et snapshot la mémoire + l'état CPU
2. Fork (~0.8ms) : Crée une nouvelle VM KVM, mappe la mémoire du snapshot en CoW, restaure tout l'état CPU
3. Isolation : Chaque fork est une VM KVM distincte avec isolation mémoire matérielle

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)");

Documentation

• Référence de l'API
• Guide de déploiement
• Architecture

Statut

Prototype fonctionnel. La primitive de fork, les benchmarks et l'API sont réels, mais pas encore durcis pour la production. Ouvrez un ticket si ça vous intéresse.

Auto-hébergement ou service managé

Zeroboot est open source. Hébergez-le vous-même sur n'importe quelle machine Linux avec KVM, ou utilisez l'API managée :

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

Nous construisons le service managé pour les équipes qui ne veulent pas gérer leur propre infrastructure. Inscrivez-vous pour un accès anticipé : https://tally.so/r/aQGkpb

Limitations connues

• Les forks partagent l'état du CSPRNG du snapshot. L'entropie du noyau est réensemencée via RNDADDENTROPY mais les PRNG de l'espace utilisateur (numpy, OpenSSL) nécessitent un réensemencement explicite par fork. Voir les recommandations de Firecracker.
• Un seul vCPU par fork. Multi-vCPU est architecturalement possible mais pas implémenté.
• Pas de réseau dans les forks. Les sandbox communiquent uniquement par entrée/sortie série.
• Les mises à jour du modèle nécessitent un nouveau snapshot complet (~15s). Pas de patch incrémental.

Licence

Apache-2.0