Resource Limits
Each sandbox is provisioned with the following resources:| Resource | Guaranteed | Maximum (burst) |
|---|---|---|
| CPU | 0.5 cores | 4.0 cores |
| Memory | 1 GB | 16 GB |
Timeouts
| Timeout | Duration | Description |
|---|---|---|
| Max session | 2 hours | The maximum lifetime of a sandbox. After 2 hours, the sandbox is automatically shut down. Re-opening the project creates a new sandbox. |
| Idle timeout | 10 minutes | If there’s no activity (no code execution, no terminal input, no preview interaction), the sandbox shuts down to conserve resources. It restarts automatically when you return. |
| Creation timeout | 30 seconds | The maximum time allowed for a new sandbox to initialize. If it takes longer, the creation attempt is retried. |
What’s Pre-installed
Sandboxes come with a Linux environment that includes:- Python with
pipanduvfor package management - Node.js and
npmfor JavaScript projects - Common system libraries for data processing, networking, and file handling
- Git for version control operations
requirements.txt, pyproject.toml, or package.json files.
Network Access
Sandboxes have outbound internet access, which means your code can:- Call external APIs (REST, GraphQL, webhooks)
- Connect to databases and data warehouses
- Download packages and dependencies
- Fetch data from public URLs
Workspace Structure
Your project files live in the/workspace directory inside the sandbox. This is where Workshop reads and writes files when building your app. Files in this directory are persisted across sandbox restarts via a cloud volume.
A separate /persistent volume is available for data that should survive across sessions, such as installed packages or cached files.
Limitations
No GPU access
No GPU access
Sandboxes run on CPU-only infrastructure. If your project requires GPU compute (machine learning training, heavy inference), consider using an external API or running that workload elsewhere.
Session duration cap
Session duration cap
The 2-hour maximum session means long-running processes (like overnight data pipelines) need a different deployment approach. For persistent workloads, use one-click publishing to deploy your app to always-on serverless infrastructure.
No Docker or container nesting
No Docker or container nesting
You cannot run Docker containers inside the sandbox. The sandbox itself is a container — nesting is not supported.
Limited disk space
Limited disk space
The sandbox has a finite amount of disk space. Very large datasets or dependency trees may exceed the available storage. If you hit disk limits, consider streaming data from external sources instead of storing it locally.
Workarounds for Common Scenarios
| Scenario | Workaround |
|---|---|
| Need more than 2 hours of runtime | Publish your app — deployed apps have a separate, longer-lived runtime |
| Need to run a background process | Use the sandbox terminal to start processes; they persist until the sandbox times out |
| Need to access a private network resource | Use a connector to securely bridge to your private database or API |
| Need persistent storage beyond sandbox lifetime | Push your project to GitHub or download project files locally |
Sandbox vs Published App Runtime
The sandbox and published apps run on different infrastructure:| Aspect | Sandbox (development) | Published app |
|---|---|---|
| Purpose | Interactive development and testing | Production hosting for visitors |
| Session lifetime | 2 hours max, 10 min idle timeout | Long-lived, restarts automatically |
| Resources | 0.5-4 CPU, 1-16 GB RAM | Dedicated deployment resources |
| Access | Only you (the builder) | Anyone with the URL (public) or invited users (private) |
| File changes | Real-time as Workshop builds | Snapshot at time of publish; update by republishing |