Skip to content

Configure

Sandboxes

Build and verify remote Function images for Python, Shell, and imported JavaScript

Configure a remote provider and a dedicated Function base image to run Python, Shell, JavaScript imports, or custom workspace sandboxes. Plain JavaScript can run in a local isolated-vm Node worker inside the app container.

Choose the execution path

Code or block settingRuntime requirement
JavaScript without import or require, no selected sandbox or sandbox file-path referenceLocal worker; no remote provider required
Python, Shell, JavaScript importsRemote provider credentials and immutable Function image
Selected workspace sandboxRemote provider, Function base, and sandbox access
File path from another block or sandbox output pathRemote sandbox filesystem

Selecting a sandbox without a configured provider is refused with 503. File-path cases that cannot use the sandbox filesystem are refused with 422. Failing user code can also return 422; inspect the error message to distinguish the cause. A saved Python block is never silently executed as JavaScript.

Build and verify the Function base

Run these repository scripts from a checkout with dependencies installed (bun install at the repository root). Supply provider credentials to the build environment. Custom workspace sandboxes layer their packages on this base.

Code
E2B_API_KEY=... \
  bun run apps/sim/scripts/build-function-e2b-template.ts \
  --name sim-function

The builder uses E2B's maintained code-interpreter-v1 base and assigns a release generation. It prints the immutable template/build reference and generation. --generation supports release automation; --base-template accepts an immutable base override.

Set the exact values printed by that build, then verify and capture its package/runtime manifest:

Code
SANDBOX_PROVIDER=e2b \
E2B_ENABLED=true \
E2B_API_KEY=... \
E2B_FUNCTION_TEMPLATE_ID='<template>:<build-id>' \
E2B_FUNCTION_TEMPLATE_GENERATION='<release-epoch-ms>' \
SANDBOX_PARITY_MANIFEST_OUT=/tmp/function-sandbox-manifest.json \
  bun run apps/sim/scripts/verify-sandbox-parity.ts

Replace the placeholders before running. Setting SANDBOX_PROVIDER=e2b explicitly prevents an exported Daytona selection from changing this verification step.

Configure the deployment

Apply the verified runtime values through the deployment's environment or secret mechanism:

Code
SANDBOX_PROVIDER=e2b
E2B_ENABLED=true
E2B_API_KEY=...
E2B_FUNCTION_TEMPLATE_ID=<template>:<build-id>
E2B_FUNCTION_TEMPLATE_GENERATION=<release-epoch-ms>

Enable sandbox access and controls

VariableEffect
SANDBOXES_ENABLED=trueGrants the server-side sandbox entitlement on a billing-disabled self-hosted deployment
NEXT_PUBLIC_SANDBOXES_ENABLED=trueReveals the Function block's Sandbox selector; asserts readiness rather than checking it

On a billing-disabled deployment, ENTERPRISE_ENABLED=true also grants the entitlement when SANDBOXES_ENABLED is unset. The server must verify provider credentials and the immutable Function base before offering Shell and the sandbox list. Settings → Sandboxes remains in the sidebar but shows an upgrade notice until access/readiness resolves. Python remains selectable; execution still requires the remote configuration.

Set the browser flag only after provider verification succeeds. On Compose or a source checkout, bunx sim-setup doctor compares the public flag with selected-provider readiness.

Promote or roll back a build

Use the accepted E2B manifest as the release baseline. Verify the exact E2B build and any Daytona reconstruction before updating the deployment variables above.

Configure other code images

Chat's public run_function and run_code tools use a separate shell image, including plain JavaScript. The workflow-internal function_execute path uses the Function image.

Code
# E2B shell image
MOTHERSHIP_E2B_TEMPLATE_ID=<shell-template-ref>

# Daytona shell image
DAYTONA_SHELL_SNAPSHOT_ID=<shell-snapshot-ref>

These values do not replace E2B_FUNCTION_TEMPLATE_ID or DAYTONA_FUNCTION_SNAPSHOT_ID. Shell, Function, document, and Pi images have separate package contracts and release cadences. Pi also needs E2B_PI_TEMPLATE_ID or DAYTONA_PI_SNAPSHOT_ID; revealing a Pi mode with NEXT_PUBLIC_E2B_ENABLED does not supply that image.

Was this helpful?
Suggest an edit