Skip to main content
Sandboxes is in Beta, please request access here.
Your feedback is welcome, please send it to contree@nebius.com or Discord.
See Limits, retention, and usage before planning a workload.
Sandboxes gives applications and AI agents an isolated place to execute code. Use it when a task needs a runtime, tools, or dependencies to do work and return a result. Running generated code or third-party tools inside your application gives that code access to the application’s execution environment. A sandbox separates the workload from that environment: your application supplies inputs, starts the work, and collects its results. Choose which files, credentials, and network access to give the workload; see Security and data handling.

​
When to use Sandboxes

  • Give agents a place to act. Run generated code and command-line tools as part of an agent task. Return output and files so the agent can decide what to do next.
  • Test and evaluate code. Run checks on proposed changes or evaluation cases in a controlled environment, then use the results to decide whether the work meets your criteria.
  • Process data and produce files. Execute scripts that transform input files, compute results, or generate artifacts for your application to retrieve.

​
Get started

Start with Python

Run two operations with the SDK: save a file, then read it from the returned image.

Start with the CLI

Run the same save-and-reuse workflow from a terminal.

​
How execution works

Each run in Sandboxes is an operation: it starts fresh compute from an image, runs your command, and returns its output and process result. An image supplies the starting filesystem, including the tools, dependencies, and input files prepared for the task. Choose whether to save changed files as an image for the next run. A saved image contains filesystem state. It does not retain a running process, process memory, open file handles, network connections, or a live terminal. Read Execution lifecycle before building a long-running or interactive workflow. Choose whether to save filesystem changes before submitting an operation. Every operation starts fresh compute, regardless of that choice. When saving, continue only from an image returned in the result. See Execution lifecycle for the complete state model.

​
The first workflow

1

Set up access and choose an image

Set up access, then find an available base image.
2

Choose whether to save changes

Select save to request a reusable result image or discard for an operation whose filesystem changes can end with the run.
3

Submit a command

Run one command as an operation. The service starts fresh compute from the selected image.
4

Check both results

Check the operation outcome and the process exit state.
5

Record saved state

If the run saved state, record and inspect the returned image UUID before reusing it.
The persistence choice must be made before the operation is submitted. A disposable run can return output, but its filesystem changes are not a continuation point. Use Choose an interface for REST and MCP routes.

​
Build your workflow

The following recipes show how to compose individual steps within those broader jobs.

Compare two fixes

Test two patches from the same starting image and continue from the passing version.

Prepare once and reuse

Save files and dependencies once, then use them in independent operations.

Stream test progress

Watch a build or test run, reconnect to its event stream, and check the final result.

Download an artifact

Generate a binary file in an operation, download it, and verify its contents.
For interactive work, start an additional process inside an active operation and send it input.

​
What survives

​
Core identifiers

These identifiers are not interchangeable. Record immutable image UUIDs and operation IDs in reproducible workflows.

​
Continue