Choosing an environment
This page helps you get the software your Agent needs into a Workspace: use a Template the deployer published, install at runtime, or have a new Template built.
Overview
| Approach | Use it when | Survives a stop | Survives deletion | Start cost |
|---|---|---|---|---|
| Use a published Template | It already has what you need | Yes | The next Workspace has it too | None |
| Install at runtime | One session needs something extra | Best effort, or kept on a Volume | Only what is on a Volume you keep | Installed every time it is lost |
| Build a Template | Every session needs it | Yes | The next Workspace has it too | One build, then none |
Published Templates
List what your deployment offers, and look at one:
kibo template list
kibo template get kibotos-minimalWith the E2B SDK, ask the deployer for the names, and pass one to Sandbox.create.
Kibotos maintains Template definitions, including these. A deployment offers only those its deployer built and published:
| Template | Contents |
|---|---|
kibotos-minimal | A minimal system for verifying a deployment |
kibotos-coding | Debian 13 with build tools, Git, Node.js, Python, Go, and Rust, for coding Agents |
kibotos-desktop | Debian 13 with an XFCE desktop and Chromium, for Agents that operate a browser. See Desktop |
A Workspace keeps the Template revision it was created from. A new default revision affects only new Workspaces. See Workspaces and Templates.
Installing at runtime
Installing needs network access and a user allowed to install. This example allows public internet access and installs a package as root, on a Template that has apt-get:
kibo workspace network set "$workspace_id" public-internet
kibo workspace exec "$workspace_id" --user root -- sh -c 'apt-get update && apt-get install -y jq'Where the software ends up decides how long it lasts:
| Location | Stop and start | Delete the Workspace |
|---|---|---|
Root file system, such as /usr | Kept on a best-effort basis | Lost |
Volume, such as /data | Kept | Kept when the Volume is bound as in Coding Agent with a persistent project |
/tmp and /run | Lost | Lost |
Package managers usually write to the root file system. To keep a tool reliably, install it on the Volume, for example with pip install --target /data/tools, or put it in a Template. See Guarantees and limits.
Building a Template
An Operator builds a Template from a container image, publishes it, and approves it. Your image needs no change for Kibotos at runtime, but check that it works: importing does not guarantee that every image boots on both backends.
- If you are the Operator, follow Build your own Template.
- Otherwise, give the deployer the exact image digest and the checks that show it works.
Software in a Template does not need network access at runtime and costs nothing at each start.
Notes
- Environment variables are set per process:
environmentin the native API,-einkibo, andenvsinsandbox.commands.run.envsinSandbox.createreturns 501. - The kernel and guest programs belong to the Platform, not the Template. See Core concepts.
Next steps
- Creating and listing: create a Workspace from a Template.
- Network policy: allow only the destinations an install needs.
- Build your own Template: the full procedure for an Operator.
Application ports
The E2B gateway forwards HTTP and WebSocket requests for {port}-{sandboxID}.<domain> to the same port on loopback inside the sandbox. This page shows how to reach a port, how to make it private, how requests reach the application, and what to expect from desktops and Chrome DevTools.
Creating and listing
You create a Workspace from a Template with the Go SDK, the E2B SDK, or kibo workspace create, choosing its resources, network access, and Volume as you go. This page covers choosing a Template, the parameters of create, and finding Workspaces again in lists.