Sandboxes

Documentation Index

Fetch the complete documentation index at: https://arizeai-433a7140.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

A sandbox is an isolated runtime that executes a snippet of code on demand. It’s fast enough to run on every evaluation, but locked down enough that the code can’t read the host filesystem, exfiltrate secrets, or make arbitrary network calls. Phoenix uses sandboxes to run code evaluators — short Python or TypeScript functions that you write to score or judge your LLM outputs server-side, without exposing the rest of your deployment. The Settings → Sandboxes page is where administrators pick which sandbox providers are available and bundle them into named, reusable configurations that anyone writing a code evaluator can pick from. The page has two cards:

• Sandbox Providers — one row per provider. Each row lets you set the provider’s credentials, enable or disable it for your deployment, and see whether it’s currently ready to run code.
• Sandbox Configurations — named runtime profiles you create once and re-use. Each one bundles a provider with a timeout and, for hosted providers, environment variables, optional internet access, and any dependencies that should be pre-installed.

​

Local vs. hosted sandboxes

Phoenix supports two kinds of sandbox, distinguished by where the code actually runs. The badge on each row in Sandbox Providers (labeled either Local or Hosted) tells you which kind it is. A common pattern is to enable a local sandbox for the everyday case (pure-logic checks, regex, JSON diffs) and one hosted sandbox for the cases that need extra horsepower (dependencies, network calls, longer runtimes). Each provider page above has the setup steps for that provider; if you’re self-hosting and need the platform-level details (which providers are bundled in the container, how to install extras, how the allowlist works), see Sandbox Backends.

​

Sandbox Providers

A provider is a sandbox runtime that Phoenix can run code on — for example, Vercel Sandbox or Daytona. Each row in this card shows the provider’s name, the languages it supports, its current status, and a gear icon for entering credentials. Once the provider is ready to run code, an Enabled switch appears. Turning it off hides every configuration tied to that provider from the people writing evaluators, but doesn’t delete anything — flip it back on and the configurations reappear.

​

Restricting providers at the server level

The Enabled switch above is a per-deployment, admin-facing control. Self-hosted deployments can also restrict providers at the server level with the PHOENIX_ALLOWED_SANDBOX_PROVIDERS environment variable, which is set before Phoenix starts and cannot be overridden from this page.

• Leave it unset to allow every supported provider (the default).
• Set it to a comma-separated list — e.g. PHOENIX_ALLOWED_SANDBOX_PROVIDERS=WASM,DENO — to allow only those providers. Accepted values are WASM, DENO, E2B, DAYTONA, VERCEL, and MODAL (case-insensitive).
• Set it to NONE to disable every sandbox provider.

A provider that isn’t on the allowlist shows the status Disabled with the tooltip “Disabled on the server,” and its Enabled switch is unavailable. See Sandbox Backends for the full details.

​

Configuring credentials

Click the gear icon next to a provider to open the credentials dialog. The dialog lists the credential fields the backend declares — for example:

• E2B — E2B_API_KEY
• Daytona — DAYTONA_API_KEY
• Modal — MODAL_TOKEN_ID, MODAL_TOKEN_SECRET
• Vercel Sandbox — VERCEL_TOKEN, VERCEL_PROJECT_ID, VERCEL_TEAM_ID

Values are stored encrypted at rest using the server’s PHOENIX_SECRET. The dialog shows each field’s environment-variable name and a short description; required fields are marked. Local backends (Deno, WebAssembly) have no credentials, and the gear button is disabled for them.

​

Sandbox Configurations

A sandbox configuration is a named, reusable runtime profile. For a local provider it’s just a provider and a timeout. For a hosted provider it can also carry environment variables, an internet-access setting, and pre-installed dependencies. Code evaluators don’t pick a provider directly; they pick a configuration. This means administrators can set up a small set of vetted profiles — for example, “Python with requests and numpy” or “Node.js with internet access” — and the people writing evaluators just pick the profile that fits their script.

​

Creating a configuration

Click New Sandbox in the Sandbox Configurations card. Only providers that are currently available and enabled by an administrator appear in the picker. The dialog exposes the following fields. The last three are hosted-sandbox-only — when a local provider (Deno or WebAssembly) is selected they are hidden entirely.

​

Next steps

Once a configuration is in place, point an evaluator at it.