Pre-integrated sandboxes

Run tasks with local or remote environments supported by Harbor.

Harbor runs each trial in an isolated environment. Local runtimes are convenient for development; remote providers free local resources and support higher concurrency.

Harbor calls sandboxes “environments” in the CLI (--env/-e) and job configuration (environment.type). It’s a bad name, we know. But it’s too late to change now.

Run with a cloud sandbox

Sandboxes are not installed by default. Install one sandbox, such as Daytona:

uv tool install "harbor[daytona]"

Replace daytona with all sandbox options to install that sandbox. To install all pre-integrated sandboxes, use:

uv tool install "harbor[cloud]"

Local runtimes (e.g. docker) do not require optional Harbor Python dependencies, but their runtime or CLI must still be installed.

CLI

export DAYTONA_API_KEY="..."
harbor run \
  -d terminal-bench@2.0 \
  -a codex -m openai/gpt-5.6-sol \
  -e daytona \
  -n 32

Config

config.json

{
  "n_concurrent_trials": 32,
  "environment": {
    "type": "daytona"
  },
  "agents": [
    {
      "name": "codex",
      "model_name": "openai/gpt-5.6-sol"
    }
  ],
  "datasets": [
    {
      "name": "terminal-bench",
      "version": "2.0"
    }
  ]
}

export DAYTONA_API_KEY="..."
harbor run --config config.json

Alternative: run Harbor from source

When running Harbor from source, --extra daytona installs Daytona’s optional dependencies before running the command:

export DAYTONA_API_KEY="..."
uv run --no-dev --extra daytona harbor run \
  -t hello-world/hello-world \
  -a codex -m openai/gpt-5.6-sol \
  -e daytona

Harbor runs provider preflight checks when available. Otherwise, missing setup is reported when the provider starts. Important: See Environment variables to configure provider credentials and control which variables enter the sandbox.

Available sandboxes

These categories describe where a trial runs; they are documentation groupings, not separate types in Harbor’s API.

• Local runtimes execute containers on the machine running Harbor.
• Remote sandboxes run through a provider API or infrastructure that you configure.

Sandbox names and install extras

Local runtimes: docker (default), podman, apple-container, singularity

Remote sandboxes: ack (uses kubeconfig), beam, blaxel, cua-cloud (cua extra), cwsandbox, daytona, e2b, ec2, gke, hf-sandbox, hyperbrowser, islo, langsmith, modal, novita, opensandbox, openshift (uses the oc CLI), runloop, skypilot (early access), tensorlake, use-computer, vercel, wandb

Common Sandbox cli options

Flag	Purpose	Default
-e, --env	Select a built-in sandbox or custom import path.	docker
--ek, --environment-kwarg	Pass a provider-specific constructor option. Repeatable.	None
-n, --n-concurrent	Limit concurrent trials.	4
--force-build, --no-force-build	Rebuild or reuse the task environment.	--no-force-build
--delete, --no-delete	Delete or retain the sandbox after the trial.	--delete
--cpus, --memory	Choose auto, limit, request, guarantee, or ignore.	auto
--override-cpus, --override-memory-mb, --override-storage-mb, --override-gpus, --override-tpu	Override task resources for this run.	Task configuration
--env-file	Load host credentials and other environment variables. See Environment variables.	None

Provider lifetime rules can override --no-delete. Run harbor run --help for all environment options; each provider also defines its own --environment-kwarg values.

Provider capabilities

Capabilities vary by sandbox and can depend on the task mode or provider settings.

Task and hardware capabilities

Capability	Supported environments
Docker Compose	docker, podman, daytona, modal, ec2, gke, islo, langsmith, novita, blaxel, beam, hyperbrowser, vercel
GPUs	daytona, modal, gke, beam, opensandbox
TPUs	gke
Windows	docker, daytona, cua-cloud, use-computer
Host-mounted logs	docker, podman, apple-container, singularity

Modal GPU support depends on its runtime settings. GKE exposes GPUs and TPUs only for single-container tasks. cua-cloud and use-computer require their Windows platform setting.

Network capabilities

Capability	Supported environments
Disable internet	docker, podman, daytona, e2b, modal, runloop, langsmith, ec2, gke, novita, islo, tensorlake, cwsandbox, wandb, blaxel, opensandbox, beam, skypilot, hyperbrowser, vercel
Exact hostnames	docker, podman, daytona, e2b, modal, runloop, langsmith, novita, islo, tensorlake, blaxel, beam, hyperbrowser, vercel
Wildcard hostnames	docker, podman, daytona, e2b, modal, runloop, langsmith, novita, blaxel, hyperbrowser, vercel
IPv4 addresses	docker, podman, daytona, e2b, modal, novita, tensorlake, beam, hyperbrowser
IPv6 addresses	docker, podman, beam
IPv4 CIDRs	docker, podman, daytona, modal, novita, tensorlake, beam, hyperbrowser
IPv6 CIDRs	docker, podman, beam
Runtime policy changes	docker, podman, daytona, e2b, modal, novita, islo, beam, hyperbrowser, vercel

Docker and Podman require Harbor’s egress-control support. Daytona, Modal, Novita, Blaxel, and Vercel allowlists are single-container only. GKE can disable internet only in Compose mode. Islo runtime changes require its default gateway configuration.

CPU and memory capabilities

Capability	Supported environments
CPU limit	docker, podman, apple-container, modal, gke, openshift, skypilot, cwsandbox, wandb, opensandbox, ec2
CPU request	daytona, e2b, modal, runloop, gke, openshift, novita, islo, tensorlake, cwsandbox, wandb, beam, skypilot, hyperbrowser, vercel
Memory limit	docker, podman, apple-container, modal, gke, openshift, skypilot, cwsandbox, wandb, opensandbox, ec2
Memory request	daytona, e2b, modal, runloop, gke, openshift, novita, islo, tensorlake, cwsandbox, wandb, blaxel, beam, skypilot, hyperbrowser, vercel

A limit is a hard ceiling. A request reserves or selects capacity. guarantee requires both. When a provider declares resource capabilities, Harbor rejects unsupported policies before trials start.

The task’s environment definition remains the same when switching providers, subject to these capabilities.