Cua Fleet Adds Declarative Sandbox Pools and a Terraform Provider

Cua runs Fleet, a cloud service that keeps pools of virtual desktops and other sandboxes ready for AI agents. In the first of a series of short clips from its infrastructure lead, Cua argues that code is good for controlling sandboxes but awkward for provisioning them. Many sandbox services make you configure pools and warm pools, sandboxes kept running so an agent does not wait for one to boot, through code. Cua's alternative is a declarative API in its SDK: you apply a configuration describing the pool, and the system decides whether to create it, update it or leave it alone. The clip compares this to why infrastructure engineers like Kubernetes and Terraform, and says Cua also offers a Terraform provider. This account comes from an automatic transcript of the clip's audio. Its visuals were not examined.

The provider's current documentation, for a version published in mid-September after the clip, shows what a declaration contains: a pool name, CPU and memory per sandbox, the disk image to boot, and a size. Size comes in one of two forms, never both: a fixed number of warm sandboxes, or autoscaling with a minimum, starting and maximum pool size. Destroying the resource removes the pool and the namespace it owns, and a command can export an SDK-made pool as Terraform. A team can then keep its agent sandboxes in version-controlled configuration and review changes to them the way it reviews other infrastructure changes. That matters for jobs such as Cua's managed Omarchy desktops, where Cua describes the routine as creating a pool, claiming a sandbox, running the job and deleting the pool.