Introduction
Runloop is a cloud sandbox provider that offers secure, isolated execution environments for AI agents. Unlike local Docker containers, Runloop provides fully managed cloud sandboxes with powerful features including:- Cloud-native sandboxes: No local Docker installation required
- Pre-configured blueprints: Choose from optimized environment templates
- Suspend and resume: Pause sandboxes to save state and costs, then resume exactly where you left off
- Root access: Full system control when needed for package installation and configuration
- Docker-in-Docker support: Run containers inside your sandbox for complex workloads
When to Use Runloop
Choose Runloop over other sandbox providers when you need:- Cloud-hosted execution without managing infrastructure
- The ability to suspend long-running tasks and resume later
- Docker-in-Docker capabilities for containerized workloads
- Pre-configured environments for common tech stacks
- Root access for system-level operations
Prerequisites
Before getting started, ensure you have:- Python 3.10 or higher installed
uvpackage manager - Install here- OpenAI API access - For running the AI models
- Runloop platform access - For cloud sandbox provisioning
Getting Your API Keys
You’ll need API keys from both OpenAI and Runloop to use this integration.OpenAI API Key
- Navigate to https://platform.openai.com/api-keys
- Sign in to your OpenAI account (or create one if you don’t have one)
- Click “Create new secret key”
- Give your key a descriptive name like
"Agents SDK Development" - Copy the key immediately (it won’t be shown again)
- Set it as an environment variable:
Runloop API Key
- Navigate to https://platform.runloop.ai/
- Sign up for a Runloop account
- No credit card required
- $50 in free credits to get started
- Once logged in, navigate to your API settings or API keys section
- Click “Create API Key” or similar option
- Copy your API key
- Set it as an environment variable:
~/.bashrc, ~/.zshrc, or equivalent shell configuration file to make them persistent.
Installation
The Runloop sandbox backend is available as an optional extra in the OpenAI Agents SDK.Install the SDK with Runloop Support
Verify Installation
You can verify that Runloop support is installed correctly:Basic Example: Your First Runloop Sandbox
This example demonstrates the core concepts of running a sandboxed agent with Runloop:How to Run
Save the code above asbasic_runloop_example.py and run:
What’s Happening
- Manifest Creation: We define a simple workspace with two text files
- SandboxAgent: Configured with instructions and the default workspace
- RunloopSandboxClient: Manages the connection to Runloop’s API
- RunConfig: Ties together the sandbox client, options, and workflow
- Execution: The agent spins up a cloud sandbox, materializes the workspace, executes the task, and returns results
pause_on_exit=True).
Advanced Example: Docker-in-Docker with PostgreSQL Suspend/Resume
This advanced example showcases Runloop’s unique suspend/resume capability. We’ll:- Create a sandbox with Docker-in-Docker support
- Install and configure PostgreSQL
- Insert data into a database
- Suspend the sandbox (preserving all state)
- Serialize the session for later use
- Resume the sandbox from the suspended state
- Verify that installed packages, files, and database data persist
How to Run
Save the code asdockerindocker_postgres_example.py and run:
Understanding the Flow
Phase 1: Initial Setup
- Creates a sandbox using the Docker-in-Docker blueprint
- Launches with root user access (
uid=0) - Agent installs PostgreSQL via
apt - Creates database, table, and inserts data
- Creates a workspace marker file
Phase 2: Suspend
- With
pause_on_exit=True, the sandbox is suspended (not deleted) - Session state is serialized to JSON
- All installed packages, files, and database state are preserved in the cloud
- The client closes, but the sandbox remains suspended
Phase 3: Resume
- Session state is loaded from the saved JSON
- A new
RunloopSandboxClientis created - The sandbox is resumed using the
stateparameter - The suspended sandbox comes back online with all state intact
Phase 4: Verification
- Agent verifies PostgreSQL is still installed
- Workspace marker file still exists
- Database table still contains the original rows
Key Takeaways
-
State Persistence: Everything in the sandbox persists during suspend/resume:
- Installed system packages
- Filesystem contents
- Running databases and their data
- Environment variables and configurations
- Cost Optimization: Suspend sandboxes during idle periods to save costs, then resume exactly where you left off
- Serialization: Session state can be stored in databases, files, or any persistent storage for long-term management
-
Root Access: The
RunloopUserParameters(username="root", uid=0)pattern enables system-level operations - Blueprints: Different blueprints provide different capabilities (Docker-in-Docker, GPU access, etc.)
Configuration Options
RunloopSandboxClientOptions
Configure your Runloop sandbox with these options:Parameters
-
blueprint_name(str | None): Name of a pre-configured environment template- Example:
"runloop/universal-ubuntu-24.04-x86_64-dnd" - Find available blueprints in the Runloop dashboard
- Example:
-
blueprint_id(str | None): Direct blueprint ID reference (alternative toblueprint_name) -
pause_on_exit(bool): WhenTrue, suspends the sandbox instead of deleting it- Default:
False - Use for long-running tasks or to preserve state
- Default:
-
user_parameters(RunloopUserParameters | None): Custom user configuration- Controls the sandbox user and workspace root
-
name(str | None): Human-readable name for the sandbox- Appears in the Runloop dashboard
- Helpful for managing multiple sandboxes
-
timeouts(RunloopTimeouts | None): Custom timeout configuration- See RunloopTimeouts section below
-
env_vars(dict[str, str] | None): Environment variables to set in the sandbox -
exposed_ports(tuple[int, …]): Ports to expose for external access- Example:
(8080, 5432)
- Example:
RunloopUserParameters
Controls the user account in the sandbox:Parameters
-
username(str): Username for the sandbox user- Standard:
"user"(workspace root:/home/user) - Root:
"root"(workspace root:/root)
- Standard:
-
uid(int): User ID- Standard user: typically
1000or higher - Root:
0 - Must be
>= 0
- Standard user: typically
RunloopTimeouts
Fine-tune timeout settings for different operations:Parameters
All timeouts are in seconds and must be>= 1:
-
exec_timeout_unbounded_s: Maximum execution time for unbounded commands- Default:
86400(24 hours)
- Default:
-
create_s: Timeout for sandbox creation- Default:
300(5 minutes)
- Default:
-
file_upload_s: Timeout for file uploads- Default:
1800(30 minutes)
- Default:
-
file_download_s: Timeout for file downloads- Default:
1800(30 minutes)
- Default:
-
snapshot_s: Timeout for snapshot creation- Default:
300(5 minutes)
- Default:
-
suspend_s: Timeout for suspending a sandbox- Default:
120(2 minutes)
- Default:
-
resume_s: Timeout for resuming a suspended sandbox- Default:
300(5 minutes)
- Default:
-
keepalive_s: Keepalive interval- Default:
10(10 seconds)
- Default:
-
cleanup_s: Cleanup timeout- Default:
30(30 seconds)
- Default:
-
fast_op_s: Timeout for fast operations- Default:
30(30 seconds)
- Default:
Blueprints
Blueprints are pre-configured environment templates that provide specific capabilities.What are Blueprints?
Blueprints are VM images with pre-installed software, configurations, and capabilities:- Base OS with common utilities
- Runtime environments (Node.js, Python, etc.)
- Special capabilities (Docker-in-Docker, GPU access)
- Optimized configurations for specific workloads
Common Blueprints
runloop/universal-ubuntu-24.04-x86_64-dnd: Ubuntu 24.04 with Docker-in-Docker support- Use when you need to run containers inside the sandbox
- Supports
docker,docker-compose, and container orchestration
When to Use Custom Blueprints
Use custom blueprints when you need:- Docker-in-Docker: Running containerized workloads
- Specific OS versions: Ubuntu, Debian, Alpine, etc.
- Pre-installed tools: Avoid installation time on every run
- GPU access: For ML/AI workloads
- Specialized environments: Data science, web development, etc.
Finding Available Blueprints
Visit the Runloop platform dashboard to browse available blueprints, or check the Runloop documentation for the latest list.Key Features
Suspend and Resume
One of Runloop’s most powerful features is the ability to suspend a sandbox and resume it later with all state intact.How It Works
- Suspend: Instead of deleting the sandbox, Runloop creates a snapshot
- State Preservation: Everything is saved:
- Installed packages and binaries
- Filesystem contents
- Running processes (when possible)
- Database contents
- Environment variables
- Serialize: Session state can be saved to your storage
- Resume: Later, resume the sandbox from the saved state
When to Use Suspend/Resume
- Long-running tasks: Pause overnight, resume the next day
- Cost optimization: Only pay for active compute time
- Checkpointing: Save progress at key milestones
- Development workflows: Preserve complex setups between work sessions
Code Pattern
Limitations and Considerations
- Suspend time: Suspending can take 1-3 minutes depending on sandbox size
- Resume time: Resuming can take 2-5 minutes
- State size: Large filesystems take longer to suspend/resume
- Running processes: Some processes may not resume cleanly (restart them if needed)
- Costs: Suspended sandboxes may incur minimal storage costs (check Runloop pricing)
Root User Access
By default, sandboxes run as a non-root user. Root access enables system-level operations.Why You Might Need Root
- Package installation:
apt install,yum install, etc. - System configuration: Editing
/etcfiles, network setup - Service management:
systemctl, starting daemons - Docker operations: Running Docker commands (Docker-in-Docker)
How to Enable Root Access
Important Changes with Root Access
When running as root (uid=0):
- Workspace root changes:
/home/user→/root - Update your manifest:
Manifest(root="/root", ...) - HOME environment variable: Set to
/root
Security Considerations
- Use responsibly: Root access is powerful—use only when necessary
- Sandboxes are isolated: Each sandbox is a separate VM, but still be cautious
- Avoid in production: For production agents, prefer principle of least privilege
- Audit commands: Review what commands the agent executes as root
Workspace Management
The workspace is the directory where your files and code live in the sandbox.Default Workspace Roots
- Standard user:
/home/user - Root user:
/root
Creating Manifests
Use theManifest class to define workspace contents:
Reading Files from the Sandbox
During execution, use the shell tool to read files:Writing Files to the Sandbox
Agents can write files using shell commands:Archive Operations
Download the entire workspace as a tarball:Troubleshooting
Common Issues and Solutions
”Runloop sandbox examples require the optional repo extra”
Problem: You see this error when trying to import Runloop classes. Solution: Install the Runloop extra:Authentication Errors
Problem:APIStatusError: 401 Unauthorized or similar authentication failures.
Cause: Missing or incorrect RUNLOOP_API_KEY.
Solution:
-
Verify the environment variable is set:
-
Check for trailing spaces or quotes:
- Regenerate the key in the Runloop dashboard if needed
- Ensure the key is active and not expired
Timeout Errors
Problem:PollingTimeout or operation timeout errors.
Cause: Operation took longer than the configured timeout.
Solutions:
-
Increase the relevant timeout:
- Check the Runloop platform status
- Verify your network connection is stable
- Break large operations into smaller chunks
Blueprint Not Found
Problem:NotFoundError or “blueprint not found” when creating a sandbox.
Cause: Invalid blueprint_name or blueprint_id.
Solutions:
-
Verify the blueprint name spelling:
- Check available blueprints in your Runloop dashboard
-
Remove the
blueprint_nameparameter to use the default blueprint - Contact Runloop support if a specific blueprint should be available
Session Resume Failures
Problem: Cannot resume a suspended sandbox. Possible causes and solutions:-
pause_on_exitwas not set:- Ensure
pause_on_exit=Truein the originalRunloopSandboxClientOptions - Without this, the sandbox is deleted instead of suspended
- Ensure
-
Serialized state is corrupted:
- Verify the JSON is valid:
json.loads(state_json) - Re-serialize from the original state if possible
- Verify the JSON is valid:
-
Sandbox was manually deleted:
- Check the Runloop dashboard to see if the sandbox still exists
- If deleted, you’ll need to create a new sandbox
Rate Limiting
Problem:APIStatusError: 429 Too Many Requests
Cause: Exceeded Runloop API rate limits.
Solutions:
- Add exponential backoff retry logic
- Space out sandbox creation requests
- Reuse existing sandboxes when possible
- Contact Runloop to discuss rate limit increases
Out of Credits
Problem: Sandbox creation fails with billing or quota errors. Cause: Runloop account is out of credits or missing billing information. Solutions:- Check your credit balance in the Runloop dashboard
- Add more credits to your account
- Clean up unused suspended sandboxes to free resources
Additional Resources
Official Documentation
- OpenAI Agents SDK: https://github.com/openai/openai-agents-python
- Runloop Platform: https://platform.runloop.ai/
- Runloop Docs: https://docs.runloop.ai
Example Code
- OpenAI Agents Examples: https://github.com/openai/openai-agents-python/tree/main/examples
- Runloop Runner: See
examples/sandbox/extensions/runloop_runner.pyin the SDK repository
Getting Help
- OpenAI Developer Forum: https://community.openai.com/
- Runloop Support: Contact via the Runloop platform dashboard
- GitHub Issues: Report SDK issues at https://github.com/openai/openai-agents-python/issues
