ssh exe.dev new
your sandbox

// npm install @exedev/sdk
import exedev from "@exedev/sdk";

const exe = exedev({ token: process.env.EXE_TOKEN! });

// spin up a fresh sandbox for this run
const name = `sbx-${crypto.randomUUID().slice(0,8)}`;
await exe.new(name, { image: "exeuntu" });

// run any shell command via the exec API
const r = await exe.exec(`${name} -- python -c 'print(2+2)'`);
console.log(r.body); // => "4\n"

// when you're done
await exe.rm(name);

# the entire HTTPS API is one endpoint
$ curl -X POST https://exe.dev/exec \
     -H "Authorization: Bearer $EXE_TOKEN" \
     -d 'new sbx-7d3f --image alpine:latest'

$ curl -X POST https://exe.dev/exec \
     -H "Authorization: Bearer $EXE_TOKEN" \
     -d "sbx-7d3f -- python -c 'print(2+2)'"
4

# body == the SSH command. JSON output is on by default.

# the original, interactive way
$ ssh exe.dev new sbx-7d3f --image exeuntu
$ ssh exe.dev sbx-7d3f
sbx-7d3f$ python -c 'print(2+2)'
4
sbx-7d3f$ exit
$ ssh exe.dev rm sbx-7d3f

# Python SDK is coming. In the meantime, plain HTTPS works fine:
import os, httpx

r = httpx.post(
    "https://exe.dev/exec",
    headers={"Authorization": f"Bearer {os.environ['EXE_TOKEN']}"},
    content="new sbx-py",
)
print(r.text)

Get a token Read the API docs

A sandbox an agent can actually live in.

Most “AI sandboxes” are short-lived containers in a vendor’s cluster. Great for one-shot code execution. Awkward for everything else: long-running services, browser automation, databases, builds with caches, agents that come back tomorrow.

An exe.dev VM is just a Linux box. It has a public hostname, a routable IP, root, systemd, a disk that persists, and SSH on the front door. Your agent can apt install, serve HTTP, hold state across runs, and pick up where it left off.

Real isolation. KVM virtual machines, not shared kernels.
Persistent. Disks survive restarts. Stopped VMs cost disk-only.
Networked. Each VM gets a public HTTPS hostname behind exe.dev’s proxy.
Yours. Same VM you’d SSH into yourself — no proprietary container shape.

AGENT — spawning a fresh sandbox

# your agent, anywhere
$ ssh exe.dev new agent-sbx \
    --image alpine:latest
vm agent-sbx ready in 0.7s
$ ssh agent-sbx.exe.xyz \
    apt-get install -y ripgrep && rg TODO
# 30 minutes later, the agent comes back...
$ ssh agent-sbx.exe.xyz cat /work/notes.md
still here.

TOKEN — scoped, expiring, signed

$ ssh exe.dev ssh-key generate-api-key \
      --exp=24h \
      --cmds='["new","ls","rm","exec"]'
exe1.eyJleHAiOjE3M…# bearer token

# scope per-agent, per-tenant, per-run.
# revoke by deleting the SSH key.

Tokens your security team will sign off on.

API tokens carry their permissions in the token, as signed JSON. Set exp to bound replay risk, set cmds to whitelist exactly the operations an agent may perform, and embed your own ctx for tenant tagging.

Tokens are signed by your SSH key. Rotate by adding a new key. Revoke by removing one. No console required.

Secrets your agent can use, but never see.

Hand an agent an API key and one of two things happens: it refuses to touch it (“the secret is exposed!”), or it cheerfully scribbles it into memory and tries to reuse it next session, long after you’ve rotated the key.

exe.dev Integrations solve this with an HTTP proxy that lives inside your VM. The agent makes plain unauthenticated requests to an internal hostname; the proxy attaches the auth header on the way out. The secret never enters the model’s context.

Tag-based scoping. Attach an integration to a tag; tagged VMs (and their clones) get it for free.
Works for most APIs. Stripe, OpenAI, Anthropic, anything that auths via an HTTP header.
OAuth, handled. The GitHub integration is a full GitHub App — no manual token rotation.
Clone-safe. Spin off a fresh sandbox for each agent run; integrations follow automatically.

Read the design notes: Some secret management belongs in your HTTP proxy.

INSIDE THE SANDBOX — no key in sight

# the agent calls Stripe with no credentials...
$ curl https://stripe.int.exe.xyz/v1/customers \
     -d 'name=Jenny Rosen' \
     --data-urlencode 'email=jenny@example.com'
{"id": "cus_QxA…", "object": "customer", …}

# ...because the exe.dev proxy adds the Authorization header.
# the sk_live_… key never touches the agent's context window.

Two pricing models. Same VMs.

Spiky agent workloads aren’t one shape. Use pool pricing for predictable monthly capacity, or usage pricing for elastic, per-second billing.

Pool

flat monthly

A fixed bundle of CPU, RAM, disk, and transfer that your fleet of VMs shares. Spin up a thousand short-lived sandboxes against the same pool. Predictable invoice.

Personal: $20/mo — 50 VMs, 2×8 baseline
Team: $25/user/mo — burst into teammates’ capacity
Cloud Pool: from $35.84/hr — thousands of VMs, SSO, AWS VPC

See pool plans →

Usage

per second

Pay only for what an agent actually used. CPU and active memory bill by peak hourly usage; idle VMs drop to disk-only. Best for bursty agent fleets and per-tenant isolation.

CPU: $0.05 / core-hour
Active memory: $0.016 / GiB-hour
Disk: $0.08 / GiB-month
Idle VMs: no CPU charge, memory at disk rate

See usage pricing →

Need both? You can. Pool your steady-state workers, burst overflow onto usage. Talk to us: support@exe.dev.

There are many sandboxes
for AI agents,
but this one is a real computer.

exe.dev gives your agents persistent Linux VMs with root, a public hostname, and a real network stack. Drive them from your code over SSH, plain HTTPS, or the official JavaScript SDK.

Start free HTTPS API docs @exedev/sdk on npm