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 turns the brain-versus-hands separation into a concrete Cursor deployment: Cursor keeps orchestration while Vercel supplies per-request isolated execution and lifecycle machinery. It reinforces per-agent sandboxing and user-scoped identity as practical controls, while narrowing applicability to Enterprise customers. The reference architecture still leaves load performance and operating economics unproven.