zeroboot

Bacs à sable de VM inférieurs à la 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 création p50	0,79ms	~150ms	~200ms	~27ms
Latence de création 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 véritable machine virtuelle KVM avec isolation mémoire garantie par le matériel.

Fonctionnement

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

1. Template (une seule fois) : Firecracker démarre une VM, précharge votre runtime et capture un instantané de l'état mémoire + CPU
2. Fork (~0,8 ms) : crée une nouvelle VM KVM, mappe la mémoire de l'instantané en CoW, restaure tout l'état CPU
3. Isolation : chaque fork est une VM KVM distincte avec une isolation mémoire garantie par le matériel

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

Docs

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

Auteur

Zeroboot a été créé en mars 2026 et est maintenu par Adam Miribyan (@adammiribyan). Site du projet : zeroboot.dev.

Si vous utilisez zeroboot dans vos recherches, veuillez le citer ; consultez CITATION.cff ou utilisez le bouton « Cite this repository ».

Cité par

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

Si votre article ou projet utilise zeroboot, ouvrez une issue ou une pull request pour l'ajouter ici.

Statut

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

Auto-hébergement ou service managé

Zeroboot est open source. Auto-hébergez-le sur n'importe quelle machine Linux disposant de 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 développons le service managé pour les équipes qui ne souhaitent 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 issu du snapshot. L'entropie du noyau est réensemencée via RNDADDENTROPY, mais les PRNG en espace utilisateur (numpy, OpenSSL) doivent être réensemencés explicitement pour chaque fork. Voir les recommandations de Firecracker.
• Un seul vCPU par fork. Le multi-vCPU est architecturalement possible mais non implémenté.
• Pas de réseau à l'intérieur des forks. Les sandboxes communiquent uniquement via les E/S série.
• Les mises à jour de template nécessitent un nouveau snapshot complet (~15s). Pas de correctifs incrémentiels.

Licence

Apache-2.0