Cursor Cloud Agents move into self-hosted infrastructure

Cursor is opening a self-hosted path for Cloud Agents. Teams can connect laptops, VMs, or managed workers in their own network so agent tool execution stays near the code, build results, and secrets it needs. The rollout also introduces team worker pools, giving organizations a way to scale connected capacity without tying every request to one machine.

What Cursor’s self-hosted machines change

Cursor’s changelog describes three operating modes. My Machines connects one laptop or VM to an account for personal workflows. Team Pools expose named queues of workers for team or enterprise use. The pool can grow as workers connect and shrink as they disconnect, which makes capacity a property of the team’s available infrastructure rather than of a single developer workstation.

The practical distinction is where the agent runs. A self-hosted worker can keep repository access, build artifacts, and sensitive environment material inside the organization’s network boundary. That does not remove the need to review permissions: the agent still receives tasks from the Cursor service, and the worker’s local tool permissions determine what those tasks can do.

Vercel and Cloudflare show the same deployment direction

Vercel separately lists Cursor Cloud Agents in Vercel Sandbox, using isolated microVMs, scale-to-zero workers, and durable orchestration. Cloudflare’s changelog likewise documents running Cursor Cloud Agents through self-hosted machines. These are separate vendor announcements, so they corroborate the integration pattern without implying that Cursor’s feature is limited to either platform.

The common thread is infrastructure choice. A team can use a hosted sandbox for isolation and elastic capacity, or connect its own workers when network locality, internal services, or data-handling rules matter more than turnkey operations. The available choices and exact billing are vendor-specific; the announcements do not establish one universal pricing model.

What teams should verify before enabling it

Check which repositories and network destinations a worker can reach, whether build caches contain credentials, and how disconnected workers are removed from a pool. Enterprise teams should also confirm audit logging, secret injection, outbound egress controls, and the retention terms for prompts and results in the Cursor account.

For a first trial, connect a disposable VM with least-privilege credentials and a narrow repository allowlist. Measure queue time, reconnect behavior, and failed-tool recovery before adding persistent workers or production network access. Teams already using Vercel Sandbox or Cloudflare infrastructure should compare those controls with Cursor’s own worker-management settings rather than assuming the security boundary is identical.

The immediate consequence is straightforward: Cursor Cloud Agents are becoming deployable across the boundary that separates a hosted coding assistant from an organization’s own execution environment. The next operational question is whether each vendor’s controls are strong enough for the repositories and credentials teams want the agents to touch.

Sources and methodology

This report uses Cursor’s changelog as the primary source, with independent corroboration from Vercel and Cloudflare release documentation. LinkLoot’s AI workflow automation guide provides related implementation context.