Skip to main content
LaunchKit works with the real E2B cloud and with E2B-compatible planes such as Tencent CubeSandbox. Neither LaunchKit nor the bridge worker ever hardcodes an E2B hostname; plane resolution is left entirely to the e2b SDK’s standard environment variables, which is what keeps one worker binary portable across planes.

​
Pause, not kill

LaunchKit sandboxes pause when idle and resume in one to two seconds when the task continues; the sandbox’s disk must survive the pause. This matters because agent tasks are long-lived and bursty: killing idle sandboxes would lose working state, and keeping them hot would waste your capacity. Finished evaluation sandboxes are kept paused for a retention window (for debugging and re-grading — a snapshot is taken first where re-grading may still need one) and then reclaimed; the sandbox workspace is ephemeral by design, with durable results always archived to LaunchKit’s object storage. Your plane must clear two functional gates, both verified live (CubeSandbox exposes no version endpoint, so verification is always functional, never a version string):
  • Pause-on-timeout with disk parity — E2B cloud: native. CubeSandbox: requires v0.5.0 or newer. launchkit-worker doctor --probe creates a sandbox, lets it pause, reconnects, and asserts the disk survived.
  • Snapshot and fork (see Snapshots below) — E2B cloud: native. CubeSandbox: requires v0.5.1 or newer (the CubeCoW snapshot engine, hardened for spawn-from-snapshot). launchkit-worker doctor --probe runs the same snapshot round-trip the LaunchKit cloud probe runs.
Run doctor --probe at onboarding and after every plane upgrade. A plane that fails either gate is refused by the LaunchKit conformance probe: the runtime never reaches connected, and evaluation jobs on it are blocked until the plane is upgraded and re-probed.

​
Key validation

E2B’s SDK validates API keys against E2B’s own key format (e2b_...). Compatible planes use their own formats (CubeSandbox keys look like sk-cube-...), so key validation must be disabled for them:
  • Bridge mode: set E2B_VALIDATE_API_KEY=false in the worker’s environment.
  • Direct mode: tell your LaunchKit contact to disable key validation on the runtime; the conformance probe then checks reachability and API conformance rather than key authenticity, and records that scope on the runtime.

​
Private certificate authorities

An intranet plane fronted by a private CA works in bridge mode by pointing the worker at your CA bundle:
The LaunchKit cloud API itself always presents a publicly trusted certificate; SSL_CERT_FILE governs TLS verification for the worker process’s connections. Note that a bundle that replaces (rather than extends) the system store also applies to the worker’s connection to the LaunchKit cloud, so prefer a bundle that includes the public roots.

​
Template builds

Some LaunchKit features derive sandbox images (“templates”) on your plane through the E2B template-build API. The conformance probe records whether your plane supports it; planes without template-build support still run tasks on pre-built images, and your LaunchKit contact will tell you if a feature you want needs it.

​
Snapshots

LaunchKit’s evaluation and training engine snapshots sandboxes and forks new sandboxes from those snapshots (memory + disk). This is what lets a run stage its skills once and fork every trial from that prepared state, retry crashed trials from a pristine copy, and re-grade a finished trial later without re-running the agent. Snapshot support is a hard requirement of the conformance probe on every plane kind: the probe creates a sandbox, writes a marker, snapshots it, boots a second sandbox from the snapshot, and asserts the marker is present in the fork — then deletes everything it created. On CubeSandbox this functional round-trip is exactly the v0.5.1 gate: v0.5.0 passes the pause gate but fails here. A plane that fails stays in error with the failing step named on the runtime, and reconnects automatically on the next probe after the plane is upgraded.