emberdv0.1
Get started

Run agent code in a microVM, not a container.

Every sandbox gets its own kernel behind KVM. Create one, run untrusted code, throw it away — in the time a container takes to think about it.

curl -fsSL https://emberd.hdprajwal.dev/install.sh | sh

Linux + KVM · read the docs

$ curl -X POST :7777/sandboxes
{ "id": "sb_c1728b82ac4f" } # <1 ms from the warm pool
$ curl -X POST :7777/sandboxes/sb_c17.../exec \
-d '{"code":"print(6*7)"}'
{ "stdout": "42\n", "exit_code": 0 }
$ curl -X DELETE :7777/sandboxes/sb_c17...
204 No Content # VM gone, overlay discarded
43 ms
full round trip
<1 ms
create, warm pool
7 MiB
idle RAM / sandbox
0
network devices

01Lifecycle

Create. Exec. Destroy.

Read the API reference →

The whole API is three endpoints on one daemon. No fleet orchestrator, no YAML, no scheduler — a sandbox is something you make, use, and delete.

  1. POST /sandboxes

    Boot a fresh microVM — or take a pre-warmed one off the pool.

  2. POST /sandboxes/{id}/exec

    Run code inside the guest over vsock. stdout, stderr, exit code back.

  3. DELETE /sandboxes/{id}

    Tear the VM down. The overlay is discarded; nothing survives.

02Speed

Fast enough for a tool-call loop.

Hardware isolation used to mean waiting for a VM. A warm pool and snapshot restore make microVMs cheap enough to hand one to every tool call.

<1 mscreate, warm pool
43 msfull round trip
  • Warm sandboxes handed out before the boot you never see
  • create blocks on a vsock readiness probe — first exec always works
  • Measured on the reference host, not estimated
See the numbers

03Local-first

Your code stays on your machine.

One daemon, one binary

Runs on your hardware. Nothing to sign up for.

No cloud dependency

No account, no telemetry, no phone-home.

No network by default

Sandboxes get no network device unless you add one.

→Getting started

Boot your first sandbox.

three endpoints · one daemon · runs on your machine

View sourceGet started