Cursor Cloud Agents Can Now Run on Vercel Sandbox

Cursor's Cloud Agents can now execute inside Vercel Sandbox instead of only running on Cursor's own hosted machines. This is part of Cursor's Self-Hosted Machines feature, which lets teams route agent workloads onto infrastructure they operate rather than Cursor's default fleet — Vercel joins AWS Lambda, Cloudflare, Modal, Daytona, E2B, Coder, Namespace, and Kubernetes as supported platforms. It's currently gated behind a Cursor Enterprise plan, not a setting every Cursor user can flip on.

Key Takeaways

• Requires Cursor Enterprise with Self-Hosted Machines enabled by a team admin — this isn't available on regular Cursor plans.
• Cursor still runs the agent's planning and inference loop; Vercel Sandbox only supplies the isolated microVM where the agent clones code, edits files, and runs commands.
• The integration splits into a control plane (Vercel Functions + Workflow, which discovers and claims pending agent requests) and a compute plane (Vercel Sandbox, which runs the actual worker).
• Team pools scale to zero: no Sandbox runs, and nothing is billed, until a real request claims a worker.
• Vercel is one of at least eight platforms Cursor now lists as Self-Hosted Machines options.

What Is Cursor Self-Hosted Machines?

Self-Hosted Machines is Cursor's answer to "I don't want my agent's code execution happening on Cursor's servers." Cursor keeps ownership of the parts that are hard to self-host well — the agent harness and the inference loop that decides what to do next — while your own infrastructure supplies the computer where that plan actually executes: cloning the repo, editing files, running the test suite, installing dependencies.

That split matters for teams with strict data-residency or network-isolation requirements: code execution happens inside infrastructure your team controls, while Cursor's orchestration layer stays a managed service.

How Does the Vercel Sandbox Integration Work?

The setup Vercel documents uses two cooperating pieces:

A control plane, built on Vercel Functions and Vercel Workflow, runs a durable discovery loop that checks Cursor's team pool for pending requests. It polls more aggressively while requests are waiting and backs off — Vercel's guide describes an adaptive interval that stretches out after several empty checks in a row — to avoid hammering Cursor's API when there's nothing to do. When work does show up, Cursor's claim endpoint atomically assigns each pending request to exactly one worker ID, so two controllers can't grab the same job.

A compute plane is where Vercel Sandbox comes in. Each claimed request boots an isolated Firecracker microVM from a prebuilt snapshot that already has the Cursor Agent CLI installed, so there's no install step slowing down every single run. The worker inside that Sandbox picks up the job, runs until the agent goes idle, and then the Sandbox shuts itself down — that's what makes the whole pool "scale to zero" between requests instead of leaving machines running and billing you while nothing happens.

Which Platforms Support Cursor Self-Hosted Machines?

Vercel isn't the only option — Cursor ships reference worker templates for several platforms, each with a different isolation model:

• Vercel — Firecracker microVM per request, via Vercel Sandbox
• AWS Lambda — Firecracker-isolated Lambda microVM per request
• Cloudflare — one Cloudflare Container per claimed request
• Kubernetes — one Pod per claimed request, or a pool of warm idle Pods

Cursor also lists Modal, Daytona, E2B, Coder, and Namespace as supported platforms, though Vercel, AWS Lambda, Cloudflare, and Kubernetes are the ones with the most detailed public reference implementations as of this writing.

What Do You Need To Set This Up?

This isn't a checkbox in Cursor's settings — it's an infrastructure project. You'll need a Cursor Enterprise account with Self-Hosted Machines turned on, an agent-scoped team service account API key (only a Cursor team admin can create one, not a regular member key), a Vercel account with Sandbox access, and a recent Node.js runtime to build the control-plane app. The service account key stays entirely on your control plane — it's used to claim work and mint short-lived, one-hour worker tokens, and it's never copied into an agent's microVM.

Wrapping Up

This lands in the same week Cloudflare announced its own Cursor Cloud Agents integration on Cloudflare Sandboxes, which is a good signal of where this category is heading: infrastructure providers competing to be the execution layer underneath coding agents, while the agent vendors focus on orchestration. If your team is already on Cursor Enterprise and has real data-residency or isolation requirements, this is worth a look — check Cursor's Self-Hosted Machines docs and Vercel's setup guide before committing engineering time to it.