Cloud Sandbox Host

A cloud sandbox host moves the Omnigent runner from your laptop to a remote container. Your agent keeps working after you close your laptop, in an isolated environment with cloud compute.

Omnigent currently supports Modal, Daytona, and Islo as hosting platforms for cloud sandbox hosts, with more on the way.

Server-managed (recommended)

Configure your server once and anyone on the team can launch a cloud sandbox host from the web UI.

1. Install

pip install 'omnigent[modal]'       # for Modal
pip install 'omnigent[daytona]'     # for Daytona
pip install 'omnigent[islo]'        # for Islo

The Islo launcher uses the Islo Python SDK, which ships in the omnigent[islo] extra and is imported lazily, so only users of the Islo provider need to install it.

2. Set provider credentials

Modal: run modal setup to authenticate, or set MODAL_TOKEN_ID and MODAL_TOKEN_SECRET on the server.

Daytona: create an API key in the Daytona dashboard (Dashboard > Keys) and set it on the server:

export DAYTONA_API_KEY=dtn_…

Islo: create an API key with the Islo CLI (islo login, then islo api-key create omnigent --show) and set it on the server. The SDK exchanges the key for short-lived session tokens and refreshes them automatically, so the API key is the only required runtime credential:

export ISLO_API_KEY=islo_key_…
# export ISLO_BASE_URL=https://api.islo.dev      # optional, non-default API endpoint
# export ISLO_COMPUTE_URL=…                       # optional, non-default compute endpoint

3. Configure the cloud sandbox host

Add a sandbox section to your server config YAML (~/.omnigent/config.yaml on a laptop, /data/config.yaml in Docker). This is the same file where you define server-wide policies.

Only provider and server_url are required. The provider block is optional.

Modal:

sandbox:
  provider: modal
  server_url: https://your-server.example.com
  modal:
    image: ghcr.io/omnigent-ai/omnigent-host:latest  # optional, official image by default
    secrets: [omnigent-llm]                        # Modal secrets with LLM API keys

secrets injects Modal secrets (API keys, gateway URLs) into the cloud sandbox host. Values stay in Modal's secret store.

Daytona:

sandbox:
  provider: daytona
  server_url: https://your-server.example.com
  daytona:
    image: docker.io/you/omnigent-host:latest      # optional, official image by default
    env: [OPENAI_API_KEY, ANTHROPIC_API_KEY]        # server env vars to copy into sandbox

env lists env var names to copy from the server's environment into each cloud sandbox host. Values never live in the config file. A listed variable that isn't set fails the launch loudly.

Islo:

sandbox:
  provider: islo
  server_url: https://your-server.example.com
  islo:
    image: ghcr.io/omnigent-ai/omnigent-host:latest  # optional, official image by default
    env: [OPENAI_API_KEY, ANTHROPIC_API_KEY]         # server env vars to copy into sandbox
    idle_pause_after_s: 900                          # optional; null disables idle pause

Inject provider config into sandboxes (optional)

An optional top-level host_config under sandbox: (provider-agnostic — not inside a provider block like modal: or daytona:) holds verbatim in-sandbox ~/.omnigent/config.yaml content that the server installs into each sandbox before omnigent host starts. The common use is a providers: block that routes a harness through a self-hosted gateway (for example LiteLLM or vLLM):

sandbox:
  provider: modal
  server_url: https://your-server.example.com
  host_config:
    providers:
      litellm:
        kind: gateway
        default: [pi]
        openai:
          base_url: http://litellm.litellm.svc.cluster.local/v1
          api_key_ref: env:LITELLM_API_KEY
          wire_api: chat

The block is server-managed: entries injected by a previous launch are replaced or removed on the next launch or resume, so each sandbox always reflects the current config. Config created inside the sandbox under names the server never injects survives untouched.

Keep secrets out of host_config. Reference credentials with api_key_ref: env:VAR — the variable is resolved inside the sandbox against its own environment (the provider's credential lane, such as Modal secrets or copied env vars), never on the server. An inline api_key is rejected at server startup. The host_config block (and its providers: shape) is validated when the server starts, so a typo fails loudly instead of degrading silently inside the sandbox.

4. Launch from the web UI

Start a new session and select New Sandbox in the host picker. The server provisions the cloud host, starts the runner, and connects it back automatically. This works the same on both hosting platforms.

CLI

Create and manage cloud sandbox hosts from the command line. The commands are the same across hosting platforms, just switch the --provider flag.

omni sandbox create --provider modal          # or --provider daytona / islo
omni sandbox connect --provider modal \
  --sandbox-id <id> --server <url>