Choosing a Cursor Cloud Agent Runtime: Cloud, Local or Pool

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. Press Enter for the full definition. into one managed runtime and two self-hosted paths. In all three, 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.

The word carrying the most weight up there is "runtime," and it covers less ground than it sounds like it does. What actually moves between the three options is the shell around the model. That shell holds the repo checkout, runs your test command, edits files, and drives the browser. Choosing between them is therefore a choice about a machine and about who maintains it. Cursor's own security-model table further down this page puts "Cursor cloud" in all three columns of the agent-loop row.

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. Press Enter for the full definition. 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. Press Enter for the full definition., 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.

The obvious reading is that these are a checklist and any yes sends you self-hosted. That is not quite how I would use them. Question one is a yes you accept, since a written policy is a fact about your company and no amount of tunnel configuration argues with it. Two and three are yeses worth trying to disprove first, because Cursor documents a managed-path answer beside each of them.

Question three is the one I would push back on hardest. "We need a bigger machine" sounds like a hardware answer, and Cursor's setup docs put a cheaper step in front of it: cloud agents start on a default VM profile with limited memory and CPU, Enterprise plans can ask support to raise those limits for a workspace, and self-serve resource sizing is described as coming. Ask for the raise before you cost out a fleet. A custom OS, or persistent local disk for a very large repo, is the part a support ticket will not fix.

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. Press Enter for the full definition. 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.

Cursor's over-80% figure describes its own customer base and not yours, so it is a weak card to play in a design review. Where it helps is setting the burden of proof. If the plan is to self-host, someone should be able to name which of the three questions came back yes and point at the policy or the internal service that made it one.

Lowest-operations is not the same as no operations, though. Four things stay yours even on the managed path, and the first of them is where most of the setup work goes. The setup guide walks through environment configuration, and network policy sits with the three egress modes over in security and network.

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.

The line that decides this in practice is the one in the caption: a My Machines worker has to stay online while sessions run. Laptops close. One sleeps on a train, another reboots overnight for an OS update, and the session that was halfway through a test suite goes with it. For the case Cursor names, a one-off repo whose local state you would rather not recreate in the cloud, I suspect that is a fair trade. If you want to start a run and walk away from it, keep the worker on a machine that stays awake.

That per-user, per-repo binding is what puts a ceiling on scale. Four people can run four of them, and forty people have forty machines that nobody patches centrally.

A pool starts to earn its keep around there, and the feature that matters at that size is probably service account authentication rather than the Kubernetes support, because per-user worker login is the part that goes stale. With none of the three constraints in play, a small team is better off on managed than running either path. A pool needs a named owner too, since images, VM resets, capacity, credential rotation, and host failures all land with your team.

All three options support Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. 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.

The row worth slowing down on is the second one. Tool calls are where a cloud agent does damage when something goes wrong, and Cursor's security page notes that a Cloud Agent runs terminal commands without stopping for approval so it can iterate on tests, which is also what a prompt injection would need to get code out. On the managed path that happens inside an isolated VM that Cursor provisions and manages. On My Machines it happens on a machine that already holds one user's checkout and credentials, and that the same user is on the hook for keeping in a clean working state.

None of that argues against self-hosting. It does mean the perimeter question covers where an accident would land as well as where data sits at rest.

Self-hosting moves tool execution and the repository checkout onto hardware you operate. Everything else stays where it was. The agent loop runs in Cursor's cloud, and model inference still calls out to a model provider the way the desktop app does.

Worth writing that down before the compliance conversation. "Self-hosted" in a procurement thread is usually heard as covering the model too, and Cursor has no fully on-prem option: inference runs on Cursor's infrastructure or a provider's. If the rule you are working to is that nothing code-adjacent leaves your network, neither My Machines nor a pool satisfies it. Settle that before anyone builds a fleet.

When a self-hosted run misbehaves, the worker is what I would check before the network. Both paths keep the loop in Cursor's cloud, and everything the ownership table hands you sits on the worker side, from the local checkout and its dependencies to the machine's network access and whether the box is still online. On My Machines the worker has to stay up for the whole session, so rule that out first.