Skip to main content
An Environment defines the container template a Session runs on: its environment type, networking policy, preinstalled dependencies, setup script, and metadata. You can build different Environments for different scenarios: a strictly isolated audit environment, an analytics environment with data-science libraries, or an open-network environment for general development.

What an Environment Is

An Environment is the infrastructure layer beneath a Session:
  • Environment type - cloud for managed cloud containers, or self_hosted for self-hosted execution.
  • Networking policy - controls outbound network access.
  • Packages - preinstalled system, Python, and Node.js dependencies.
  • Setup script - a user shell script run after package installation during container preparation.
When a Session starts, an isolated runtime is created from the specified Environment template.

Field Reference

Config Types

config.type can be "cloud" or "self_hosted". For self_hosted, the config must be exactly:
Self-hosted Environments do not launch a managed cloud container. External workers use the Work API to poll, acknowledge, heartbeat, and stop Session work for that Environment. For cloud, the config can include networking, packages, and setup_script.

Networking Policies

config.networking supports three request modes. All modes require the object form - passing a string shorthand like "unrestricted" returns 400. Cloud Environment responses include these networking fields. Omitted fields are returned with defaults.

Open

Use this for general development tasks that need to download dependencies or call external APIs.

Limited

Use this when you don’t need arbitrary outbound traffic but still want package managers to fetch dependencies.

Allowlist

Use this for security-sensitive workloads where you must whitelist exactly which external services are reachable.

Preinstalled Packages

Use config.packages to specify dependencies installed when the container starts:
Preinstalled packages add to environment startup time. Only include packages you really need; install the rest on demand within the Session.

Setup Script

config.setup_script is a shell script executed during sandbox preparation, after packages are installed. It runs through /bin/bash -lc. Use it for initialization steps that cannot be expressed as packages - for example, cloning a repository, writing config files, or warming caches.
On success a completion marker is written inside the sandbox so the script does not run twice in the same sandbox; when the sandbox is recreated, the script runs again. A non-zero exit aborts session startup, and the error response includes the exit code and a stderr excerpt.

Create an Environment

A successful call returns 200 OK:

Create a Restricted-Network Environment

Read Environments

Update an Environment

Updating an Environment does not affect running Sessions. The new configuration applies to Sessions created after the update.

Choosing an Environment

FAQ

Q: How long do I have to wait after creating an Environment before I can use it? A: A new Environment is immediately usable. The actual container provisioning, including dependency installation, happens when a Session starts. Q: Can I pin package versions? A: pip and npm packages support pinning, such as "pandas==2.1.0" or "typescript@5.0.0". apt packages use the default version from the system repository. Q: An incorrect networking setting is breaking my Agent. What should I do? A: Create a new Environment (or update the existing one) with corrected networking, then start a new Session. Q: How many Environments can I create per account? A: There is no hard limit. Create only what you need and use a naming convention to keep things organized.

Next steps

Start a session

Combine an Agent and an Environment to start running tasks.

Agent setup

Review Agent configuration.