zeroboot

Sandbox de VM em submilissegundos para agentes de IA via fork copy-on-write

Experimente

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

Cada sandbox é uma máquina virtual KVM real com isolamento de memória reforçado por hardware.

Como funciona

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

1. Template (única vez): O Firecracker inicializa uma VM, pré-carrega seu runtime e tira um snapshot da memória + estado da CPU
2. Fork (~0,8ms): Cria uma nova VM KVM, mapeia a memória do snapshot como CoW, restaura todo o estado da CPU
3. Isolamento: Cada fork é uma VM KVM separada com isolamento de memória 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)");

Documentação

• Referência da API
• Guia de Implantação
• Arquitetura

Status

Protótipo funcional. A primitiva de fork, os benchmarks e a API são reais, mas ainda não estão prontos para produção. Abra uma issue se tiver interesse.

Auto-hospedado ou gerenciado

Zeroboot é código aberto. Hospede você mesmo em qualquer máquina Linux com KVM ou use a API gerenciada:

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

Estamos construindo o serviço gerenciado para equipes que não querem administrar sua própria infraestrutura. Inscreva-se para acesso antecipado: https://tally.so/r/aQGkpb

Limitações conhecidas

• Os forks compartilham o estado do CSPRNG do snapshot. A entropia do kernel é re-semeada via RNDADDENTROPY, mas PRNGs em userspace (numpy, OpenSSL) precisam de re-semeamento explícito por fork. Veja o guia do Firecracker.
• Único vCPU por fork. Múltiplos vCPUs são arquitetonicamente possíveis, mas não implementados.
• Sem rede dentro dos forks. Os sandboxes se comunicam apenas via E/S serial.
• Atualizações de template exigem um novo snapshot completo (~15s). Sem patches incrementais.

Licença

Apache-2.0