Skip to main content
Recipes that give each task its own container get it from a sandbox provider. Rows are providers, columns the connectors that can use them; a filled cell has had a real rollout run on it. Each column header links to the connector’s recipe, and a check carries its own link where that pair runs on a different one. The rest of this page is how to set each provider up. Its SDK is installed per recipe; the recipe README has that line. Every provider takes its credential the same two ways: exported in the environment, or in a key file. On a multi-host cluster the file has to be readable where the rollout workers run — a shared filesystem, or the same path on every node — because the launcher hands the workers the file’s path, never its contents.

​
E2B

E2B Cloud, or any server that speaks the E2B API.
With nothing else set, the SDK talks to E2B Cloud. For a server of your own, point both planes at it:
AgentENV is one such server — Firecracker microVMs behind the E2B API — and deploying one is its own guide. E2B Cloud builds templates as a non-root user, so a task Dockerfile whose RUN layers need root fails to build there. Terminal-Bench-2 tasks ship prebuilt images and are unaffected.

​
Daytona

Accounts carry a total-disk quota: keep concurrent sandboxes × per-sandbox disk under it. A Harbor recipe sizes that disk with HARBOR_OVERRIDE_STORAGE_MB. The credential is a token pair, kept in the config file Modal’s CLI writes:
MODAL_TOKEN_ID + MODAL_TOKEN_SECRET in the environment work as well; one half without the other is treated as missing. MODAL_PROFILE and MODAL_ENVIRONMENT pick the workspace when the profile’s default is not the one you want.