zeroboot

Sub-Millisekunden-VM-Sandboxes für KI-Agenten mittels Copy-on-Write Forking

Ausprobieren

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

Jede Sandbox ist eine echte KVM-VM mit hardwaregestützter Speicherisolation.

So funktioniert es

  Firecracker-Snapshot ──► mmap(MAP_PRIVATE) ──► KVM-VM + wiederhergestellter CPU-Zustand
                              (copy-on-write)         (~0.8ms)

1. Vorlage (einmalig): Firecracker startet eine VM, lädt Ihre Laufzeitumgebung vor und erstellt einen Snapshot von Speicher und CPU-Zustand
2. Fork (~0.8ms): Erstellt eine neue KVM-VM, bildet den Snapshot-Speicher als CoW ab und stellt den gesamten CPU-Zustand wieder her
3. Isolation: Jeder Fork ist eine separate KVM-VM mit hardwaregestützter Speicherisolation

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

Dokumentation

• API-Referenz
• Bereitstellungsanleitung
• Architektur

Status

Funktionsfähiger Prototyp. Die Fork-Primitive, Benchmarks und API sind echt, aber noch nicht produktionsreif. Eröffnen Sie ein Issue, wenn Sie Interesse haben.

Eigenbetrieb oder verwaltet

Zeroboot ist Open Source. Betreiben Sie es selbst auf einem beliebigen Linux-Rechner mit KVM oder nutzen Sie die verwaltete API:

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

Wir bauen den verwalteten Dienst für Teams, die keine eigene Infrastruktur betreiben möchten. Melden Sie sich für den frühen Zugang an: https://tally.so/r/aQGkpb

Bekannte Einschränkungen

• Forks teilen den CSPRNG-Zustand aus dem Snapshot. Die Kernel-Entropie wird per RNDADDENTROPY neu ausgesät, aber Userspace-PRNGs (numpy, OpenSSL) benötigen explizites Neusäen pro Fork. Siehe Firecrackers Hinweise.
• Einzelne vCPU pro Fork. Multi-vCPU ist architektonisch möglich, aber nicht implementiert.
• Keine Vernetzung innerhalb der Forks. Sandboxes kommunizieren nur über serielle Ein-/Ausgabe.
• Vorlagenaktualisierungen erfordern einen vollständigen neuen Snapshot (~15s). Keine inkrementellen Patches.

Lizenz

Apache-2.0