Daytona Sandboxing
Relevant source files
The following files were used as context for generating this wiki page:
Daytona Sandboxing provides isolated, per-agent execution environments within the SynthCrowd platform. The primary purpose of this system is to ensure that each synthetic browser agent operates in a clean state, preventing the sharing of cookies, sessions, or local storage between different personas during testing iterations. Sources: plan.md, src/lib/daytona.ts:25-30
Within the broader architecture, Daytona acts as the infrastructure layer for the Phase 2: TEST stage of the pipeline. It hosts local versions of target sites, allowing the Code Modification Agent to apply changes and the Browser Use agents to navigate the modified code in a controlled environment. Sources: plan.md, src/test-smoke.ts:114-118
System Architecture
The sandboxing system is built around the @daytonaio/sdk and is managed via a dedicated library that abstracts sandbox lifecycle operations. Every agent launch is preceded by the creation of a unique sandbox instance tied to a specific run and persona index. Sources: src/lib/daytona.ts:1-10, package.json:20
Sandbox Lifecycle Management
The lifecycle of a sandbox involves initialization, environment configuration, and cleanup. The system uses a singleton pattern for the Daytona client to manage connections to the "us" target provider. Sources: src/lib/daytona.ts:9-18
The diagram above illustrates the linear lifecycle of a Daytona sandbox from creation to destruction during a single agent execution. Sources: src/lib/daytona.ts:22-45, plan.md
Core Components
| Component | Description | File Reference |
|---|---|---|
Daytona | The primary SDK client used to communicate with the Daytona API. | src/lib/daytona.ts:12 |
createSandbox | Function that initializes a new TypeScript sandbox for a specific agent. | src/lib/daytona.ts:22 |
destroySandbox | Function that safely deletes a sandbox instance and logs the result. | src/lib/daytona.ts:43 |
Sandbox | Type definition representing an active Daytona execution environment. | src/lib/daytona.ts:3 |
Implementation Details
Environment Configuration
When a sandbox is created, specific metadata is injected via environment variables. This ensures the execution environment is context-aware regarding the current simulation run and the specific persona it represents. Sources: src/lib/daytona.ts:29-33
// src/lib/daytona.ts:28-35
const sandbox = await daytona.create({
language: "typescript",
envVars: {
SYNTHCROWD_RUN_ID: runId,
SYNTHCROWD_PERSONA_INDEX: String(personaIndex),
},
});
Integration with Test Pipeline
The sandboxing system is integrated into the parallel runner. While the agents browse, Daytona provides the isolation necessary to maintain "Persona Fidelity"—ensuring that a "Grandma" persona's session doesn't inherit technical state from a previous "Tech Bro" session. Sources: plan.md, src/test-smoke.ts:114-118
This sequence diagram shows the communication flow between the SynthCrowd orchestrator and the Daytona infrastructure during an agent test run. Sources: src/lib/daytona.ts:22-45, plan.md
Configuration Requirements
To utilize Daytona sandboxing, the following environment variables must be configured:
| Variable | Description |
|---|---|
DAYTONA_API_KEY | Authentication key for the Daytona SDK to provision resources. |
SYNTHCROWD_RUN_ID | Automatically injected into sandboxes to track the session. |
SYNTHCROWD_PERSONA_INDEX | Automatically injected to identify the specific persona in the sandbox. |
Sources: src/lib/daytona.ts:13-15, src/lib/daytona.ts:30-31
Conclusion
Daytona Sandboxing is critical for the "Prove the fix works" differentiator of SynthCrowd. By providing isolated environments, the system can rerun the exact same personas against modified code in a clean-room state, ensuring that conversion rate improvements are a result of code changes rather than cached session data. Sources: plan.md, src/lib/daytona.ts:37-41