the problem

Where does that code run today?

When customers, a security review or a contract say “the code stays here”, none of these work.

the answer

$ The sandbox runs on your side of the line.

integrate

Four ways in. Same sandbox.

The whole agent loop — exec, files, git, PTY, sessions, snapshots, preview URLs — behind one API. Non-zero exits come back as values, so the error goes straight back to the model. The REST API and the Python SDK are part of every evaluation package; the TypeScript SDK, the MCP server and the CLI are delivered on request, according to your stack.

from sandfort_sdk import Client

client = Client(base_url=URL, api_key=KEY)
sbx = client.create_sandbox(snapshot="python:3.12-slim", wait=True)

r = sbx.process_exec(argv=["sh", "-c", "echo build; exit 7"])
# r.exit_code == 7  (returned, not raised)

run = sbx.code_run("python", "print(21 * 2)")
# run.exit_code == 0, run.stdout.strip() == "42"

sbx.fs.upload_file("/tmp/hello.txt", b"hello\n")
sbx.delete()

import { SandfortClient } from "@sandfort/sdk";

const client = new SandfortClient({ baseUrl: URL, apiKey: KEY });
const sbx = await client.createSandbox({ snapshot: "python:3.12-slim" });

const r = await sbx.codeRun("python", "print(21 * 2)");
console.log(r.exitCode, r.stdout);  // 0 42

// sessions, async commands, fs, git, snapshots, volumes

$ sandfort login
$ sandfort sandbox create demo --snapshot python:3.12-slim --wait
$ sandfort exec sbx_… python3 -c "print(21 * 2)"
42
$ sandfort cp ./app sbx_…:/work/app
$ sandfort shell sbx_…           # interactive PTY

{ "mcpServers": { "sandfort": {
    "command": ".venv/bin/python",
    "args": ["mcp_server/sandfort_mcp.py"],
    "env": { "SANDFORT_BASE_URL": URL, "SANDFORT_API_KEY": KEY }
} } }

# tools any MCP client gets:
# create_sandbox · run_code · run_command · create_snapshot
# upload_text_file · download_text_file · list_sandboxes · delete_sandbox

isolation

Assume the code is hostile.

$ :(){ :|:& };:                      # fork bomb
bash: fork: retry: Resource temporarily unavailable
$ curl -m 3 http://169.254.169.254/  # cloud credentials
curl: (7) Failed to connect to 169.254.169.254 port 80
$ env | grep SANDFORT_
(no output)
$ ls /var/run/docker.sock
ls: cannot access '/var/run/docker.sock': No such file

network

Reach the API it needs. Nothing else.

POST /v1/sandboxes
{
  "snapshot": "python:3.12-slim",
  "egress_allowlist": ["example.com"]
}

$ curl -sI https://example.com
HTTP/2 200   # CONNECT tunnel through the proxy
$ curl -sI https://other.example.net
curl: (56) CONNECT tunnel failed, response 403
# same proxy, forged credential
$ curl -sI --proxy-user sbx:wrong https://example.com
curl: (56) CONNECT tunnel failed, response 407

guardrails

Built for agents that misbehave.

speed

Fast enough for the inner loop.

Two measurements, each one run on one host, same script (20 creates waiting for started, 50 short commands in one sandbox, alpine:3.20 pre-pulled). macOS laptop, 2026-11-01: arm64, Docker 29.8.2. Linux beta VM, 2026-11-03: a KubeVirt VM with 6 vCPU on a shared Hetzner host (nested virtualization, not bare metal), Ubuntu 24.04, Docker 29.9.2, XFS project-quota storage. Neither is an SLO, and neither is a comparison with any other product. The hosted beta is a shared evaluation instance, not a benchmark environment: measure on your own host.

operations

Runs where you already run.

Same codebase and the same API from the first experiment to the security review. TLS terminates in front of the API.

identity and access

Your identity provider decides who gets in.

SSO and SCIM are self-hosted configuration features; they are not enabled on the hosted evaluation beta, which uses API keys.

engineering

Measured, not promised.

Tests: pytest --collect-only, 2026-11-04. Operations: counted in the exported OpenAPI spec, 2026-11-04 (includes /healthz and /readyz). Gates: scripts in examples/. CI: green on GitHub as of 2026-11-03. The audit log is a per-organization hash chain; audit-verify exits non-zero on any break, so a self-hosted operator can put it in cron. On the hosted evaluation beta that check runs operator-side; customers read their events through the audit API.

compared with e2b

If you use E2B today.

Both can be self-hosted. They differ in what the host needs, how a sandbox is isolated by default, and what ships with the platform.

E2B facts checked 2026-11-04 against github.com/e2b-dev/infra (README and license); they can change. This is not a feature-by-feature comparison, and it says nothing about E2B's hosted service.

honest limits

What it does not do (yet).

The hosted beta is a shared evaluation instance: no SLA, best-effort support, no production secrets, not for benchmarks. The governance details behind the connect guide (scopes per endpoint, rate-limit buckets, usage metering, what the audit log records and redacts, webhook delivery) come in a governance reference shipped with the evaluation package.

next step

Looking for 2–3 design partners.