Skip to main content
By default, an agent’s sandbox runs wherever capacity is available, usually in the United States. To run sessions closer to your users or systems, set region in the agent’s opencomputer.toml and deploy again:

​
Allowed values

region takes one of the values below. OpenComputer places the agent’s sandbox in that region, and creates session state in the nearest Cloudflare location: A broad region (us, eu, ap) lets the sandbox run anywhere inside it, so it starts sooner when capacity is tight. A narrow region pins it more precisely.
  • Values are lowercase and exact. "AU" and cloud zone names such as "ap-southeast-2" or "us-east-1" are rejected.
  • The value must be a quoted string. region = au is rejected.
  • To go back to the default, remove the region line and deploy again.
An unsupported value stops the deploy before anything is uploaded:
The API rejects it too, with 400 unsupported_region, if you call POST /v1/deployments directly.

​
What the region covers

  • Sandbox. The agent’s sandbox, where sandbox_exec and other tools run, is created in the region. Its outbound traffic leaves from that region too.
  • Session state. Session state is created near the region. This placement is best effort.
  • Not moved. Account-level data, such as project and deployment records, stays where it is.

​
Changing the region

A region change applies to sessions started after the deploy. Existing sessions stay where they started. Each agent in a project has its own opencomputer.toml, so agents in one project can run in different regions.

​
Cold starts

The first session after you deploy to a new region is slower to start. The agent’s sandbox image has to be pulled into that region, and the first tool call can take a few minutes. Later sessions reuse the cached image and start much faster. To take the cold start before your users do, start one session that runs a command after the deploy. The sandbox starts only on the first tool call, so a session that only chats does not warm it: