zeroboot

Субмиллисекундные VM-песочницы для AI-агентов через копирование при записи (copy-on-write fork)

---

Попробовать

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

Бенчмарки

Метрика	Zeroboot	E2B	microsandbox	Daytona
Задержка запуска p50	0.79ms	~150ms	~200ms	~27ms
Задержка запуска p99	1.74ms	~300ms	~400ms	~90ms
Память на песочницу	~265KB	~128MB	~50MB	~50MB
Fork + exec (Python)	~8ms	-	-	-
1000 параллельных fork	815ms	-	-	-

Каждая песочница — это настоящая KVM-виртуальная машина с аппаратной изоляцией памяти.

Как это работает

  Снимок Firecracker ──► mmap(MAP_PRIVATE) ──► KVM VM + восстановленное состояние CPU
                              (копирование при записи)         (~0.8ms)

1. Шаблон (однократно): Firecracker загружает VM, предварительно загружает ваше окружение и делает снимок памяти + состояния CPU
2. Fork (~0.8ms): Создаёт новую KVM VM, отображает память снимка как CoW, восстанавливает всё состояние CPU
3. Изоляция: Каждый fork — отдельная KVM VM с аппаратной изоляцией памяти

SDK

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

Документация

• Справочник API
• Руководство по развёртыванию
• Архитектура

Статус

Рабочий прототип. Fork-примитив, бенчмарки и API реальны, но ещё не закалены для продакшена. Откройте issue, если заинтересованы.

Самостоятельный хостинг или управляемый сервис

Zeroboot с открытым исходным кодом. Разверните самостоятельно на любом Linux-сервере с KVM или используйте управляемый 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))"}'

Строим управляемый сервис для команд, которые не хотят запускать собственную инфраструктуру. Зарегистрируйтесь для раннего доступа: https://tally.so/r/aQGkpb

Известные ограничения

• Forks разделяют состояние CSPRNG из снимка. Энтропия ядра возобновляется через RNDADDENTROPY, но пользовательские PRNG (numpy, OpenSSL) требуют явного перезапуска для каждого fork. См. рекомендации Firecracker.
• Один vCPU на fork. Многопроцессорная архитектура возможна, но не реализована.
• Нет сети внутри forks. Песочницы общаются только через последовательный I/O.
• Обновление шаблона требует полного повторного снимка (~15с). Инкрементального патчинга нет.

Лицензия

Apache-2.0