Skip to main content
Create a sandbox for an agent’s task, wait for it to deploy, and delete it when the work finishes. Use a Baseten SDK to manage sandboxes from your application. Each SDK creates and refreshes sandbox access tokens for you. Use the Baseten CLI or the dashboard to inspect and troubleshoot sandboxes by hand. You need permission to create resources in your team.

Set up

Install the CLI or an SDK:
The CLI examples use $SANDBOX_NAME for the sandbox name:
Sandbox commands are in pre-release. Arguments, flags, and output may change.

Create a sandbox

Creating a sandbox starts an isolated environment from an image. The new sandbox gets a name, an image, memory (which also sets its CPU allocation), and a region. Name, image, memory, and region can’t change after creation.
An organization can run up to 10 sandboxes at once. To raise this quota, contact Baseten support with your organization ID.
The call waits until the sandbox is ready. To reuse a live sandbox with the same name, set createIfNotExists: true.

Get a sandbox

A sandbox’s record shows its configuration, URL, and current status.
To work with the sandbox, not just its record, use client.get({ name: "hello-world" }).
If the status is FAILED, inspect the sandbox’s logs before retrying. For the deployment and deletion statuses, see Lifecycle and expiration.

Interact with a running sandbox

You can interact with a sandbox in two ways:
  • Use the Management API, through the CLI or an SDK, to:
    • Create sandboxes.
    • List sandboxes.
    • Update sandboxes.
    • Delete sandboxes.
  • Use the sandbox’s own API, served by a server inside each sandbox at the sandbox’s url field, to:
    • Run commands.
    • Read, write, and edit files.
The sandbox’s server URL is the url field the create or get call returns. Get the URL before connecting:
Use the URL exactly as the API returns it. Direct HTTP calls and MCP clients need it, and the CLI and SDKs look it up for you: Anatomy of a sandbox server URL. In https://sbx-hello-world-abc123.us-pdx-1.b10.run, hello-world is the sandbox name, abc123 identifies the sandbox's team, and us-pdx-1 is the region. Anatomy of a sandbox server URL. In https://sbx-hello-world-abc123.us-pdx-1.b10.run, hello-world is the sandbox name, abc123 identifies the sandbox's team, and us-pdx-1 is the region. To connect to a sandbox: Connect with an interactive terminal, direct HTTP calls, an SDK, or an MCP client:
The SDK wraps the sandbox’s API with file and process methods:
For operations the SDK doesn’t wrap, sandbox.raw_api is the generated client, and client.sandbox_from_url(url=...) builds a sandbox from a URL you already have.
Applications that need tighter control than the MCP server’s tools define their own functions instead. The sandbox’s MCP server is separate from the Baseten MCP, which manages deployments and models across your workspace.

Run commands in a sandbox

Run a single command in a deployed sandbox. Its output streams to your terminal, and its exit code becomes the command’s exit code.
To set extra environment variables for one command, set env:

Set environment variables

Environment variables pass configuration, such as an output format or log level, to the processes in a sandbox, so one image can serve different tasks. Set them at creation. Names begin with a letter or underscore and contain only letters, digits, and underscores. Don’t put your Baseten API key in a sandbox’s environment.
Set secret: false for a value you want to read back later.
Values are secret by default. Secret values are masked as **** when you read them back, so use them for credentials and tokens. For configuration you’ll want to see later, such as LOG_LEVEL or OUTPUT_FORMAT, mark the value as not secret so it stays readable. A describe shows the difference:
To read a secret value back, add --show-secrets to describe, or read the variable inside the sandbox. Don’t pass --plain-env or secret: false for credentials; those values are stored and returned in plain text.

List sandboxes

Filter by status with statuses, such as statuses: ["DEPLOYED"].

Manage a sandbox’s labels

Labels help you find and group sandboxes, such as marking every sandbox an agent creates with purpose=agent. This example changes the purpose label from hello-world to hello-universe:
A supplied set of labels replaces all previous labels, so include every one you want to keep. Omitted fields leave their values unchanged. You can also update environment variables with envs. The name, image, memory, and region can’t change after creation. To use a different image, create a new sandbox.

Delete a sandbox

Deletion stops the sandbox’s processes and permanently removes its files, so save the files you need first.
Deletion continues after the call returns. Stop sending work to the sandbox, then describe the sandbox until its status is TERMINATED. The sandbox reports TERMINATED for a few minutes, and then it’s no longer found. Don’t reuse the name until deletion completes.

Work in a team

If you belong to multiple teams, specify a team ID when you create an SDK client:

Handle a failed command

Use the error message to choose the next action:

Next steps

Sandbox lifecycle and expiration

Track deployment status and set an expiration policy.

Manage sandbox images

Choose a built-in image, or create and version your own.