Skip to main content

Workspace volumes

The executor fleet is a warm pool of executor pods; an agent is a directory on a fleet volume, and every turn runs in its own sandbox against that directory. The fleet needs a StorageClass that mounts XFS with project quotas; fleet.storage.createClass: true creates one, or name an existing one in fleet.storage.className. Without it the fleet refuses to start rather than run unbounded. Sizing and the idle guard are on Sizing and requirements. The Computer view in Xpander Chat is the workspace as a file browser; credential stores such as .aws, .ssh and .kube never appear in it. See Agent workspace.

Object storage

Baseline volumes on a self-hosted install are 48 GiB for the chart’s stores plus 5 GiB per workspace-using agent. Object storage is Supabase Storage. By default it keeps its objects on an in-cluster volume. On AWS it can instead keep them in an S3 bucket you own. Authentication uses the pod’s own identity, IRSA or EKS Pod Identity, so no key is stored in the chart:
The bucket needs versioning off and public access blocked; the role needs get, put, delete and list on that bucket alone. On an air-gapped sealed VPC the S3 gateway endpoint is required in either case, for ECR image pulls.

S3 as a skill

Agents reach your buckets through the Amazon S3 skill, one of the AWS skills served by the AWS Operator in your cluster. Calls are signed with a per-skill IAM role assumed by the operator, so no bucket credential is ever handed to an agent. The role design is on IAM best practices; the skill’s actions are on Amazon S3.