Cursor Cloud Agents can now run in Vercel Sandbox
Cursor Cloud Agents can execute inside per-request Vercel microVMs, giving teams control over isolation, credentials, retries, and worker lifecycle without operating persistent VMs.
Cursor now lets Cloud Agents run on **Vercel Sandbox** through its Self-Hosted Machines APIs. Cursor retains the harness and inference loop, while each request gets an isolated **Firecracker microVM**; Vercel Functions and Workflow handle queues, provisioning, monitoring, retries, and cleanup.
This separates agent orchestration from execution infrastructure. Teams needing tighter runtime control can use scale-to-zero workers and short-lived, user-scoped credentials instead of maintaining a standing VM pool.
Cursor now lets Cloud Agents run on **Vercel Sandbox** through its Self-Hosted Machines APIs. Cursor retains the harness and inference loop, while each request gets an isolated **Firecracker microVM**; Vercel Functions and Workflow handle queues, provisioning, monitoring, retries, and cleanup. This separates agent orchestration from execution infrastructure. Teams needing tighter runtime control can use scale-to-zero workers and short-lived, user-scoped credentials instead of maintaining a standing VM pool. Self-Hosted Machines requires a **Cursor Enterprise** plan, and the source describes a reference implementation rather than its operating cost or performance under load.
This makes the brain-versus-hands split deployable for Cursor: Cursor keeps orchestration while Vercel supplies isolated, per-request execution and lifecycle machinery. It reduces the need for a standing worker fleet and supports user-scoped credentials, but narrows access to Enterprise customers and leaves cost, capacity, and load behavior to be validated.