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
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.
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:
Replace the placeholders before running. Setting SANDBOX_PROVIDER=e2b explicitly prevents an exported Daytona selection from changing this verification step.
The API key needs write:snapshots to build and write:sandboxes to execute. The builder reconstructs packages from an accepted E2B manifest: complete the E2B build and verification first, even when Daytona is your runtime provider.
Use the snapshot ID printed by the builder and verify it against the accepted E2B baseline:
Replace the placeholders before running.
Configure the deployment
Apply the verified runtime values through the deployment's environment or secret mechanism:
Enable sandbox access and controls
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.
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.