Cursor Cloud Agents: Choosing a Runtime

Cursor splits Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. into one managed runtime and two self-hosted paths. The shared fact is that the agent loop always runs in Cursor's cloud; the runtime choice only changes where tool calls execute and who operates that execution environment. The cards below summarize each option as Cursor describes it.

Cursor frames the choice as a decision tree: if any answer is "yes," pick a self-hosted path; otherwise managed Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. are the default. The list below walks the three questions Cursor poses, each of which points to self-hosting when it applies.

• Perimeter constraint: Do written policies require repository data and agent compute to stay inside your perimeter? Cursor notes this is usually required by compliance or security policy, not just a team preference.
• Network reach: Do agents need in-network services that Tailscale, PrivateLinkAn AWS feature that keeps traffic to a service on your private network instead of the public internet., and egress allowlists cannot cover? Most private networks work with Cursor-hosted agents via those mechanisms.
• Hardware or disk: Do you need a custom OS, special hardware, or persistent local disk for a very large repo? Cursor-hosted agents run on Ubuntu VMs and use a Dockerfile to customize tooling; if ARM is required, Cursor says to talk to your enterprise account team.

Cursor calls managed Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. usually the lowest-operations way to give agents secure access to code and internal systems, and recommends using the managed path when you can configure access through its built-in controls. The list below covers the access mechanisms Cursor documents for the managed path.

• Cloud Agent environments with setup commands, Dockerfiles, snapshots, and secrets.
• Network access controls that restrict outbound domains by user, team, or environment.
• Tailscale or a similar private-network client inside the environment when agents need to reach services in your VPC or intranet.
• Private connectivity for private GitHub Enterprise Server, GitLab Enterprise, private source control APIs, and related webhook traffic.

This lets Cursor operate the agent infrastructure after setup while your team controls which repos, secrets, and network resources each environment can reach. On the managed path your responsibilities are first-time environment configuration, secrets, repository access, and network policy; Cursor manages the host and environment lifecycle after that.

The two self-hosted paths serve different scales. My Machines is for personal or small-scale workflows on a specific user's machine, while Self-Hosted Pool is for Enterprise teams that want centralized ownership of worker hardware. The table below maps each to the cases Cursor documents.

All three options support Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code. and controlled secrets. Cursor says the main difference is where tool execution happens and who operates that execution environment. The table below contrasts the three runtimes on the questions Cursor documents.