Principle:OpenHands OpenHands Provider Authentication
| Knowledge Sources | |
|---|---|
| Domains | Cloud_Infrastructure, Runtime_Management |
| Last Updated | 2026-02-11 21:00 GMT |
Overview
Provider Authentication is the principle of establishing authenticated connections with cloud sandbox providers using API credentials, enabling OpenHands to create and manage isolated execution environments across multiple third-party platforms.
Description
OpenHands supports four third-party cloud runtime providers: Daytona, E2B, Modal, and Runloop. Each provider requires its own set of API credentials (API keys, tokens, or configuration objects) to authorize sandbox creation and management operations. Rather than implementing authentication logic ad hoc for each provider, OpenHands employs a strategy pattern where all four runtimes inherit from a common base class, ActionExecutionClient, and each implements provider-specific authentication within its constructor.
The base class defines the shared interface for action execution, health checking, and lifecycle management. Each concrete runtime class accepts a unified OpenHandsConfig object that contains provider-specific credentials (e.g., Daytona API keys, E2B API tokens, Modal secrets, Runloop bearer tokens). During initialization, each runtime extracts its relevant credentials from the configuration and constructs the appropriate provider SDK client.
This design ensures that:
- The orchestrator layer does not need to know which provider is in use.
- New providers can be added by implementing the same base class interface.
- Authentication failures surface early, during runtime construction, rather than during sandbox operations.
Usage
Provider Authentication is invoked whenever a new runtime instance is created for an agent session. The orchestrator selects the appropriate runtime class based on configuration, constructs it with the shared config object, and the constructor handles all provider-specific credential validation and client initialization.
Theoretical Basis
The strategy pattern is used to decouple provider selection from authentication mechanics. All four runtimes share the same abstract interface through ActionExecutionClient, and each provides its own authentication strategy.
INTERFACE ActionExecutionClient:
method __init__(config, event_stream, sid, ...)
method connect() -> None
method close() -> None
method run(action) -> Observation
method run_ipython(action) -> Observation
method _wait_until_alive() -> None
CLASS DaytonaRuntime EXTENDS ActionExecutionClient:
method __init__(config, event_stream, sid, ...):
EXTRACT daytona_api_key FROM config
CREATE DaytonaConfig WITH api_key, server_url, target
CREATE Daytona client WITH daytona_config
CALL super().__init__(config, event_stream, sid, ...)
CLASS E2BRuntime EXTENDS ActionExecutionClient:
method __init__(config, event_stream, sid, ...):
EXTRACT e2b_api_key FROM config
SET E2B environment variable WITH api_key
CALL super().__init__(config, event_stream, sid, ...)
CLASS ModalRuntime EXTENDS ActionExecutionClient:
method __init__(config, event_stream, sid, ...):
EXTRACT modal_api_token_id, modal_api_token_secret FROM config
CONFIGURE modal credentials
CALL super().__init__(config, event_stream, sid, ...)
CLASS RunloopRuntime EXTENDS ActionExecutionClient:
method __init__(config, event_stream, sid, ...):
EXTRACT runloop_api_key FROM config
CREATE Runloop client WITH api_key
CALL super().__init__(config, event_stream, sid, ...)
The key invariant is that after construction, every runtime instance holds a valid, authenticated provider client ready to create sandboxes. The shared constructor signature allows the orchestrator to treat all runtimes polymorphically.