Migrate from E2B#

TaskCloud covers the same core workflow as E2B: create a sandbox from a template, run commands, read and write files, expose ports, pause and resume. Most migrations are a mechanical rename. This page maps the concepts and lists the differences in behavior.

E2B compatibility adapter: Coming soon. We plan an adapter that lets existing E2B SDK code run against TaskCloud after you change the import and the API key. Until it ships, use the mapping below.

E2B's SDKs change over time. The E2B names below describe its public SDK in general terms; check E2B's current documentation for exact signatures.

What changes conceptually#

API and SDK mapping#

Before and after#

// E2B (illustrative)
// const sbx = await Sandbox.create("my-template");
// const r = await sbx.commands.run("python app.py");
// const url = `https://${sbx.getHost(3000)}`;

// TaskCloud
import { Client } from "@taskcloud/sdk";

const client = new Client(); // reads TASKCLOUD_API_KEY
const sandbox = await client.sandboxes.create({ template: "my-template" });
const r = await sandbox.exec({ command: "python app.py", timeout_seconds: 120 });
console.log(r.exit_code, r.stdout);

await sandbox.exec({ command: "python -m http.server 3000", background: true });
const { url } = await sandbox.ports.expose({ port: 3000, visibility: "public" });

from taskcloud import Client

client = Client()
sandbox = client.sandboxes.create(template="my-template")
r = sandbox.exec(command="python app.py", timeout_seconds=120)
print(r.exit_code, r.stdout)

Templates#

E2B templates are typically built from a Dockerfile. On TaskCloud:

1. Build and push the image to any OCI registry: docker build -t ghcr.io/acme/env:1 . && docker push ....
2. POST /templates with {"name": "my-template", "image": {"ref": "ghcr.io/acme/env:1"}}. Add start_command and ready_check if something must be running before the snapshot is taken.
3. Create sandboxes with template: "my-template". The template is a RAM snapshot, so a new sandbox starts with your processes already running (target p95 < 500 ms).

A second option: set up one sandbox by hand, take a snapshot and turn it into a template (snapshot_id). See Templates.

Timeouts: think "idle" instead of "max lifetime"#

An E2B sandbox usually lives for a fixed time window. A TaskCloud sandbox is meant to persist, and the controls are:

• auto_pause.idle_timeout_seconds (default 300): pause after this much idle time. Paused sandboxes cost $0 for compute, and the next exec, file, port, SSH or desktop request wakes them (target p95 < 800 ms).
• ttl_seconds: delete the sandbox automatically after N seconds. Use it for one-off jobs.
• always_on: true: never pause (fixed monthly price, default size only).

So a typical "give every user their own VM" setup is: create one sandbox per user, keep it forever, and let auto-pause handle cost. See Lifecycle.

Cost comparison#

Hourly price for 4 vCPU / 8 GB, according to battleships.dev as of 2026-10: E2B $0.331 per hour; TaskCloud default $0.030 per active hour.

Example: 1000 VMs, each active 10% of the time (73 h/month):

Your numbers depend on your plan and usage. Check current pricing on both sides. See Billing.

Checklist#

• [ ] Create a TaskCloud API key with the full-sandbox preset (POST /api-keys)
• [ ] Rebuild custom templates from your image (POST /templates)
• [ ] Replace SDK calls using the table above (snake_case fields, e.g. timeout_seconds, background)
• [ ] Replace per-session timeouts with auto_pause and/or ttl_seconds
• [ ] Update preview URLs to https://<short_id>-<port>.taskhost.cloud
• [ ] Subscribe to webhooks (sandbox.ready, sandbox.paused, sandbox.error, ...)
• [ ] Handle errors by error.code and error.retryable (see API reference)