Managed Agents

Cloud environment setup

Create a long-lived cloud environment, pick its VM template and git repos, and bind sessions to it.

View as Markdown

An environment is a long-lived Firecracker VM that sessions execute inside. Binding a session to an environment gives the agent VM-backed tools — shell, file read/write, and patch — operating on the repos cloned into that VM.

Reach for an environment when you want a VM that persists across many sessions. For a one-off VM that's provisioned and torn down around a single job, use an on-demand run instead.

Create an environment

Create an environment with a name, a VM template, and the git repos to clone into it. The Console also lets an agent carry a default environment spec (template

  • repos) that its runs provision automatically — set it under the agent's Environment / VM field.

POST /v1/environments with a name and a config. Only config.type (always cloud in v1) is required within the config.

curl https://agents.clusterbase.dev/v1/environments \
  -H "Authorization: Bearer $CLUSTER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "web-dev",
    "config": {
      "type": "cloud",
      "template_id": "development",
      "git_repos": [{ "url": "https://github.com/acme/web", "branch": "main" }]
    }
  }'

Templates

config.template_id selects the VM image: development (the default when omitted), workspace, browser, or desktop. The cloud sandbox reference describes what each one is for, what it has installed, its compute and disk, and its network limits.

Git repos

config.git_repos are cloned into the VM when it's first provisioned. Each repo clones as the VM's owner, so private repos pull with that identity's GitHub credentials. A repo lands at /home/user/<name> unless you set an explicit path. Per-repo clone outcomes surface on a bound session's cloned_repos, including a warning if a particular repo failed to clone.

{ "url": "https://github.com/acme/web", "branch": "main", "path": "web" }

Networking and packages

In v1, config.networking supports only unrestricted — limited is rejected until network filtering ships. config.packages is accepted and stored but not yet installed — only the template's pre-installed tools are available.

Bind a session

Pass environment_id when creating a session. The VM is provisioned on the first binding and reused afterwards. The caller must own the environment — an unknown or non-owned id returns 404.

curl https://agents.clusterbase.dev/v1/sessions \
  -H "Authorization: Bearer $CLUSTER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "agent": "agt_3f9c2a", "environment_id": "env_9a8b7c" }'

Lifecycle

List with GET /v1/environments, fetch one with GET /v1/environments/{id}. Archiving (POST /v1/environments/{id}/archive) or deleting (DELETE /v1/environments/{id}) tears the VM down.

A session created without an explicit environment_id gets its own environment, owned by that session. Deleting the session tears that environment down too — no separate DELETE /v1/environments/{id} call is needed. Passing an existing environment_id to a session instead detaches it from any session that created it, so it survives deletion of either session.

On this page