Sandbox Lifecycle
VoidRun sandboxes are designed for long-running workloads with intelligent resource management. Unlike traditional serverless functions that timeout, VoidRun sandboxes can run indefinitely while optimizing costs through smart hibernation.Infinite Running
VoidRun sandboxes are designed to run forever. There’s no maximum execution time limit, making them ideal for:- Long-running AI agent workflows
- Persistent development environments
- Multi-step code execution pipelines
- Background processing tasks
♾️ No Timeouts
Sandboxes don’t have a maximum execution time. Run tasks for minutes, hours, or days.
💰 Cost Efficient
Auto-sleep ensures you only pay for active compute time, not idle time.
⚡ Instant Resume
Resume sleeping sandboxes in under 200ms, maintaining the illusion of always-on availability.
Auto-Sleep & Resume
VoidRun automatically optimizes resource usage by putting idle sandboxes to sleep.How Auto-Sleep Works
Activity Monitoring
VoidRun monitors sandbox activity (command execution, file operations, network requests).
State Preservation
The sandbox state is preserved—files, environment variables, and running processes are saved.
The 5-minute idle timeout is configurable at the organization level. Contact support to adjust this setting for your use case.
Lightning-Fast Resume
When you interact with a sleeping sandbox, it resumes automatically in under 200ms:- Transparent: Resume happens automatically—no manual wake-up needed
- Fast: Sub-200ms resume time feels instantaneous
- Stateful: All files, environment variables, and configurations are preserved
Resume Time Comparison
| Platform | Cold Start | Resume Time |
|---|---|---|
| VoidRun | ~2s (new sandbox) | < 200ms |
| AWS Lambda | ~1-5s | N/A |
| Traditional VMs | ~30-60s | ~10-30s |
| Containers | ~5-15s | ~2-5s |
Manual Lifecycle Controls
Take full control over sandbox state with manual lifecycle operations.Pause a Sandbox
Manually pause a running sandbox to release resources while preserving state:Resume a Sandbox
Resume a paused or sleeping sandbox:Stop a Sandbox
Stop a running sandbox completely (stronger than pause):Start a Sandbox
Start a stopped sandbox:Terminate a Sandbox
Permanently delete a sandbox and all its data:Lifecycle States
| State | Description | Billing | Resume Time |
|---|---|---|---|
| Running | Sandbox is active and processing | Billed at full rate | N/A |
| Paused | Manually paused, state preserved | Billed at reduced rate | < 200ms |
| Sleeping | Auto-slept due to inactivity | Not billed | < 200ms |
| Stopped | Manually stopped | Not billed | ~2s (cold start) |
Best Practices
Cost Optimization
Let sandboxes auto-sleep when not in use. The sub-200ms resume time means there’s virtually no latency penalty, while you save on compute costs.
Long-Running Workflows
For workflows that need to maintain state over long periods:- Use persistent storage: Critical data should be persisted to files or external storage
- Handle resume gracefully: Design your code to handle potential pauses
- Use health checks: Implement periodic health checks for critical long-running processes
Example: Long-Running AI Agent
Next Steps
Code Execution
Learn how to execute commands and code inside sandboxes.
File System
Understand file storage and operations in sandboxes.