Sandbox Management
Sandboxes are isolated development environments managed by Daytona. This guide covers how to create, manage, and remove Sandboxes using the SDK.
Creating Sandboxes
Daytona SDK provides an option to create Sandboxes with default or custom configurations. You can specify the language, image, resources, environment variables, and volumes for the Sandbox.
By default, the sandboxes auto-stop after 15 minutes
of inactivity in order to save resources but the timeout can be increased.
Basic Sandbox Creation
Daytona SDK provides methods to create Sandboxes with default configurations, specific languages, or custom IDs using Python and TypeScript.
from daytona_sdk import Daytona
daytona = Daytona()
# Create a basic Sandbox
sandbox = daytona.create()
# Create a Sandbox with specific language
params = CreateSandboxParams(language="python")sandbox = daytona.create(params)
# Create a Sandbox with custom ID
params = CreateSandboxParams(id="my-sandbox")sandbox = daytona.create(params)
import { Daytona } from '@daytonaio/sdk';
const daytona = new Daytona();
// Create a basic Sandboxconst sandbox = await daytona.create();
// Create a Sandbox with specific languageconst sandbox = await daytona.create({ language: 'typescript' });
// Create a Sandbox with custom IDconst sandbox = await daytona.create({ id: 'my-sandbox' });
Sandbox Resources
You can configure the compute resources allocated to your Sandbox using the SandboxResources
class. This allows you to specify the number of CPU cores, the memory and disk space.
from daytona_sdk import Daytona, CreateSandboxParams, SandboxResources
daytona = Daytona()
# Create a Sandbox with custom resources
resources = SandboxResources( cpu=2, # 2 CPU cores memory=4, # 4GB RAM disk=20, # 20GB disk space)
params = CreateSandboxParams( language="python", resources=resources)
sandbox = daytona.create(params)
import { Daytona } from '@daytonaio/sdk';
const daytona = new Daytona();
// Create a Sandbox with custom resourcesconst sandbox = await daytona.create({ language: 'typescript', resources: { cpu: 2, // 2 CPU cores memory: 4, // 4GB RAM disk: 20, // 20GB disk space }});
Sandbox Information
Daytona SDK provides methods to get information about a Sandbox, such as ID, root directory, and status using Python and TypeScript.
# Get Sandbox IDsandbox_id = sandbox.id
# Get the root directory of tha Sandbox user
root_dir = sandbox.get_user_root_dir()
# Get the Sandbox name, image and state
name = sandbox.instance.nameimage = sandbox.instance.imagestate = sandbox.instance.state
// Get Sandbox IDconst sandboxId = sandbox.id;
// Get the root directory of tha Sandbox userconst rootDir = await sandbox.getSandboxRootDir();
// Get the Sandbox name, image and stateconst name = sandbox.instance.nameconst image = sandbox.instance.imageconst state = sandbox.instance.state
To get the preview URL for a specific port, check out Preview & Authentication.
Remove Sandbox
Daytona SDK provides methods to perform operations on Sandboxes, such as removing Sandboxes using Python and TypeScript.
# Remove Sandboxdaytona.remove(sandbox)
// Remove Sandboxawait daytona.remove(sandbox);
Sandbox States and Persistence
Daytona keeps the filesystem in its entirety during the Sandbox lifecycle. The persistence functionality is built into the system, and nothing needs to be explicitly done from the user side.
Auto-stop Interval
It is important to understand the Sandbox states to maintain cost-effectiveness. One useful built-in feature is the auto-stop interval. By default, it triggers after 15 minutes
of inactivity by stopping the Sandbox, but the number can changed to any value, including 0
which disables auto-stopping.
sandbox = daytona.create(CreateSandboxParams( language = "python", auto_stop_interval = 0 # Disables the auto-stop feature - default was 15 (minutes)))
const sandbox = await daytona.create({ language: 'typescript', autoStopInterval: 0 // Disables the auto-stop feature - default was 15 (minutes)});
A Daytona Sandbox can have three states during its lifecycle:
Running
Running Sandboxes utilize CPU, memory, and disk storage. Every resource is charged per second of usage. When Sandboxes are not actively used, it is recommended that they be stopped. This can be done:
- Manually using the stop command
- Automatically by setting the autoStop interval
Stopped
Stopped Sandboxes only utilize disk storage. They can be instantly started when needed. The stopped state should be used when the Sandbox is expected to be started again soon. Otherwise, it is recommended to archive the Sandbox to eliminate disk usage costs.
Archived
When Sandboxes are archived, the entire filesystem state is moved to very cost-effective object storage, making it possible to keep Sandboxes available for an extended period.
Performance Considerations
The tradeoff between archived and stopped states is that starting an archived Sandbox takes more time, depending on its size.