Sandbox profile · Open-source project

OpenHands Runtime

Answer in brief

The sandbox layer of the OpenHands agent SDK: an agent server that runs in a Docker container, in-process locally, or on the hosted OpenHands Runtime API. The right sandbox layer if you are already building on the OpenHands SDK; elsewhere a general container or microVM sandbox is simpler.

By the Agent Sandboxes editors · Updated November 9, 2026

Overview

The OpenHands software agent SDK ("Python, TypeScript, and REST APIs for building agents that work with code") separates the agent from where it runs. The runtime layer is the agent server: DockerWorkspace pulls a pre-built image such as ghcr.io/openhands/agent-server:latest-python, starts the container, waits for the server and tears it down afterwards; DockerDevWorkspace builds from a custom base image; a local workspace runs in the same process with no isolation; and APIRemoteWorkspace connects to the hosted OpenHands Runtime API. The SDK README also mentions ephemeral workspaces "in Docker or Kubernetes".

The Docker image bundles the execution tools, optional VS Code Web and VNC for browser tools. The docs warn that the Runtime API is "designed primarily for benchmark evaluation at scale" and point production users to OpenHands Cloud Workspace with "fully managed sandbox environments with SaaS credential support". The runtime and SDK are MIT-licensed; no maturity label appears on the runtime pages. This record covers the runtime layer only, not the OpenHands agent or app.

Notable

Agent server images published at ghcr.io/openhands/agent-server; exposes a REST/WebSocket API
Hosted Runtime API is documented as "designed primarily for benchmark evaluation at scale"
SDK licensed MIT and powers the OpenHands CLI and OpenHands Cloud

OpenHands Runtime specifications

Attribute	Details
Isolation	Docker container running the agent-server image (DockerWorkspace), with the agent proxying commands and file transfer over HTTP/WebSocket; a local in-process workspace has no isolation; the hosted Runtime API runs the image in a "sandboxed environment" whose mechanism is not named
Deployment	Open-source project · Self-hostable
Open source	Yes (MIT)
SDKs and interfaces	Python, JavaScript/TypeScript, REST API
Cold start (vendor claim)	Not documented
Max session length	Not documented
Persistence	Docker workspaces are "automatically stopped and cleaned up" when the context exits; persistence beyond a session is not documented on the runtime pages
GPU	Not documented
Networking	Agent server exposed on a host port (examples use 8010); extra_ports exposes VS Code Web (port+1) and VNC (port+2); client talks over HTTP and WebSocket
Pricing	Free to self-host (MIT). The hosted Runtime API requires a RUNTIME_API_KEY; pricing is not published on the runtime docs
Free tier	Free to self-host
Compliance	Not documented
Regions	Not documented

Facts from OpenHands Runtime’s public documentation, verified November 9, 2026. Performance numbers are vendor claims.

Strengths and trade-offs

Strengths

You run OpenHands agents and want their execution isolated in disposable containers
You need a VNC-visible browser and VS Code inside the sandbox
You run large benchmark sweeps and want a hosted runtime for the same image

Trade-offs

Container isolation only; no microVM option is documented
Persistence, limits and hosted pricing are not documented on the runtime pages
Tightly coupled to the OpenHands SDK rather than a general-purpose sandbox API

Good fit for: Running OpenHands agents in disposable Docker sandboxes, locally or in CI, with the same server reachable through a hosted runtime for large evaluations.

Use cases OpenHands Runtime fits

RL & evals: Disposable Docker sandboxes for OpenHands agents, with a hosted runtime option for large evaluations.

How OpenHands Runtime compares

Sandbox	Isolation	Open source	Self-host / BYOC	Cold start (vendor)	Max session	Snapshots / pause	GPU	SDKs
OpenHands Runtime	Docker container	Yes	Yes / No	Not documented	Not documented	Not documented / Not documented	Not documented	Python, JavaScript/TypeScript, REST API
SWE-ReX	Docker / Modal / Fargate	Yes	Yes / No	Not documented	Not documented	No / Not documented	Not documented	Python, REST API
LLM Sandbox	Docker/Podman/K8s container	Yes	Yes / No	Not documented	Not documented	No / Not documented	Not documented	Python, MCP server
Docker Sandboxes	MicroVM	No	Yes / No	Not documented	Until removed (local)	Yes / Yes	Yes	sbx CLI, TypeScript (cloud), REST API (cloud)
Daytona	Containers or VMs	No	Not documented / Yes	<90 ms	Unlimited	Yes / Yes	Yes	Python, TypeScript, Ruby, Go, Java
E2B	Firecracker microVM	Yes	Yes / Yes	Not documented	1 h / 24 h (Pro)	Yes / Yes	No	Python, JavaScript/TypeScript
Kubernetes Agent Sandbox	gVisor or Kata	Yes	Yes / Yes	<1 s (warm pool)	Not documented	Yes / Yes	Yes	Kubernetes CRDs, Python, kubectl

See all OpenHands Runtime alternatives →

Frequently asked questions

What is OpenHands Runtime?

How does OpenHands Runtime isolate code?

OpenHands Runtime documents its isolation as: Docker container running the agent-server image (DockerWorkspace), with the agent proxying commands and file transfer over HTTP/WebSocket; a local in-process workspace has no isolation; the hosted Runtime API runs the image in a "sandboxed environment" whose mechanism is not named.

Is OpenHands Runtime open source?

Yes (MIT). It can be self-hosted.

How much does OpenHands Runtime cost?

Free to self-host (MIT). The hosted Runtime API requires a RUNTIME_API_KEY; pricing is not published on the runtime docs Check the official pricing page for current rates.

What are the alternatives to OpenHands Runtime?

Common alternatives include SWE-ReX, LLM Sandbox, Docker Sandboxes, Daytona, E2B, Kubernetes Agent Sandbox. See OpenHands Runtime alternatives for a full comparison.

Sources

Cite this page

Agent Sandboxes. (2026). OpenHands Runtime. agentsandboxes.org. Last reviewed November 9, 2026. https://agentsandboxes.org/sandboxes/openhands-runtime/

Found an error or a missing sandbox? Submit a correction — every entry links to the sources it relies on.