Devboxes

Initialize and start

Sign in with exo login, then initialize from your repository. Local mode requires Docker; cluster mode requires access to an Industric deployment. Initialization detects languages and harness settings and saves the choices in devbox.yaml.

exo devbox init --runtime local

exo devbox start

exo devbox init --runtime cluster --deployment my-deployment

exo devbox start

Detach with Ctrl+P, Ctrl+Q and reattach with exo devbox attach. Local --mounted mode shares repository edits directly with the host. Copy mode keeps a separate workspace; save changes held only inside it before recreating the container.

Sessions and movement

exo devbox status

exo devbox sessions

exo devbox replay <session-id>

exo devbox resume <session-id>

exo devbox mv --runtime cluster my-deployment

The platform stores the spec, lifecycle, and recorded event stream, including terminal timing and supported harness transcripts. Devbox records are tenant-visible. Reads require devboxes:read; writes require devboxes:write.

Cluster workspace lifecycle

Cluster devboxes now use the Devbox custom resource under autonomic.sh/v1alpha1. The workspace is mounted at /workspace; its PVC survives stop and idle eviction. Explicit removal with exo devbox rm deletes the workspace PVC.

Install the current CRDs and RBAC before restarting the operator. Existing Sandbox-backed devboxes transition through an explicit stop and start, reusing their workspace PVC. Copy out files from the old container's writable layer first. A custom workspace claim must be retained when creating the replacement resource.

Repository tools

Generated local images include gh; GitLab, Bitbucket Cloud, and Forgejo repositories add glab, bb, or tea. Select an ambiguous self-hosted forge with --git-provider during initialization. Authenticate inside the devbox or explicitly pass credentials through copy.env; choosing a provider does not change network policy.

For pull-request workflows, see Code Review & Composer. For automated tests, see Testboxes.