Skip to main content
A comprehensive guide to integrating Runloop cloud sandboxes with the OpenAI Agents SDK.

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
For more details, visit the official Runloop documentation.

Prerequisites

Before getting started, ensure you have:
  • Python 3.10 or higher installed
  • uv package 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

  1. Navigate to https://platform.openai.com/api-keys
  2. Sign in to your OpenAI account (or create one if you don’t have one)
  3. Click “Create new secret key”
  4. Give your key a descriptive name like "Agents SDK Development"
  5. Copy the key immediately (it won’t be shown again)
  6. Set it as an environment variable:

Runloop API Key

  1. Navigate to https://platform.runloop.ai/
  2. Sign up for a Runloop account
    • No credit card required
    • $50 in free credits to get started
  3. Once logged in, navigate to your API settings or API keys section
  4. Click “Create API Key” or similar option
  5. Copy your API key
  6. Set it as an environment variable:
You can add these to your ~/.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:
If you see the success message, you’re ready to proceed!

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 as basic_runloop_example.py and run:

What’s Happening

  1. Manifest Creation: We define a simple workspace with two text files
  2. SandboxAgent: Configured with instructions and the default workspace
  3. RunloopSandboxClient: Manages the connection to Runloop’s API
  4. RunConfig: Ties together the sandbox client, options, and workflow
  5. Execution: The agent spins up a cloud sandbox, materializes the workspace, executes the task, and returns results
The sandbox is automatically created, the agent executes the task, and then the sandbox is cleaned up (unless 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:
  1. Create a sandbox with Docker-in-Docker support
  2. Install and configure PostgreSQL
  3. Insert data into a database
  4. Suspend the sandbox (preserving all state)
  5. Serialize the session for later use
  6. Resume the sandbox from the suspended state
  7. Verify that installed packages, files, and database data persist

How to Run

Save the code as dockerindocker_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 RunloopSandboxClient is created
  • The sandbox is resumed using the state parameter
  • 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

  1. State Persistence: Everything in the sandbox persists during suspend/resume:
    • Installed system packages
    • Filesystem contents
    • Running databases and their data
    • Environment variables and configurations
  2. Cost Optimization: Suspend sandboxes during idle periods to save costs, then resume exactly where you left off
  3. Serialization: Session state can be stored in databases, files, or any persistent storage for long-term management
  4. Root Access: The RunloopUserParameters(username="root", uid=0) pattern enables system-level operations
  5. 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
  • blueprint_id (str | None): Direct blueprint ID reference (alternative to blueprint_name)
  • pause_on_exit (bool): When True, suspends the sandbox instead of deleting it
    • Default: False
    • Use for long-running tasks or to preserve state
  • 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
  • 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)

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)
  • uid (int): User ID
    • Standard user: typically 1000 or higher
    • Root: 0
    • Must be >= 0
When using root (uid=0), the default workspace root changes from /home/user to /root.

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)
  • create_s: Timeout for sandbox creation
    • Default: 300 (5 minutes)
  • file_upload_s: Timeout for file uploads
    • Default: 1800 (30 minutes)
  • file_download_s: Timeout for file downloads
    • Default: 1800 (30 minutes)
  • snapshot_s: Timeout for snapshot creation
    • Default: 300 (5 minutes)
  • suspend_s: Timeout for suspending a sandbox
    • Default: 120 (2 minutes)
  • resume_s: Timeout for resuming a suspended sandbox
    • Default: 300 (5 minutes)
  • keepalive_s: Keepalive interval
    • Default: 10 (10 seconds)
  • cleanup_s: Cleanup timeout
    • Default: 30 (30 seconds)
  • fast_op_s: Timeout for fast operations
    • Default: 30 (30 seconds)

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

  1. Suspend: Instead of deleting the sandbox, Runloop creates a snapshot
  2. State Preservation: Everything is saved:
    • Installed packages and binaries
    • Filesystem contents
    • Running processes (when possible)
    • Database contents
    • Environment variables
  3. Serialize: Session state can be saved to your storage
  4. 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 /etc files, 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
The workspace root is automatically set based on the user, but you can override it in your manifest.

Creating Manifests

Use the Manifest class to define workspace contents:

Reading Files from the Sandbox

During execution, use the shell tool to read files:
Or use the sandbox session API:

Writing Files to the Sandbox

Agents can write files using shell commands:
Or programmatically:

Archive Operations

Download the entire workspace as a tarball:
Upload a workspace archive:

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:
Verify with:

Authentication Errors

Problem: APIStatusError: 401 Unauthorized or similar authentication failures. Cause: Missing or incorrect RUNLOOP_API_KEY. Solution:
  1. Verify the environment variable is set:
  2. Check for trailing spaces or quotes:
  3. Regenerate the key in the Runloop dashboard if needed
  4. 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:
  1. Increase the relevant timeout:
  2. Check the Runloop platform status
  3. Verify your network connection is stable
  4. 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:
  1. Verify the blueprint name spelling:
  2. Check available blueprints in your Runloop dashboard
  3. Remove the blueprint_name parameter to use the default blueprint
  4. Contact Runloop support if a specific blueprint should be available

Session Resume Failures

Problem: Cannot resume a suspended sandbox. Possible causes and solutions:
  1. pause_on_exit was not set:
    • Ensure pause_on_exit=True in the original RunloopSandboxClientOptions
    • Without this, the sandbox is deleted instead of suspended
  2. Serialized state is corrupted:
    • Verify the JSON is valid: json.loads(state_json)
    • Re-serialize from the original state if possible
  3. 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:
  1. Add exponential backoff retry logic
  2. Space out sandbox creation requests
  3. Reuse existing sandboxes when possible
  4. 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:
  1. Check your credit balance in the Runloop dashboard
  2. Add more credits to your account
  3. Clean up unused suspended sandboxes to free resources

Additional Resources

Official Documentation

Example Code

Getting Help