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

Cursor offers one managed runtime and two self-hosted configurations, which its docs group as Self-Hosted Machines. In all three, the agent loop runs in Cursor's cloud. The choice changes where tool calls execute and who operates that execution environment.

The word "runtime" covers less ground than it sounds. What moves between the three options is the shell around the model: the repo checkout, file edits, terminal commands, computer-use tools and local MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers. So the choice is about a machine and who maintains it. Cursor's own comparison table puts "Cursor cloud" in all three columns of the agent-loop row.

Cursor frames the choice as a decision tree with three questions. If any answer is yes, it points you to a self-hosted configuration. 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.

Taken as a checklist, any yes sends you to self-hosting. We read the questions differently. A yes to the first is a fact about your company, and no tunnel configuration argues with a written policy. Yeses to the second and third are worth trying to disprove first, because Cursor documents a managed-path answer beside each of them.

Push back hardest on the third. "We need a bigger machine" sounds like a hardware answer, but Cursor's setup docs put a cheaper step in front of it. Those docs say a default VM profile caps memory and CPU, that support can lift the caps for Enterprise workspaces, and that self-serve sizing is coming soon. Ask for the raise before you cost out a fleet. A custom OS, or persistent local disk for a large repo, is what a support ticket won't fix.

On chip architecture, Cursor's runtime page gives two answers. Cursor-hosted VMs run on x86_64 (amd64). For arm64, the top of the page says to run a self-hosted worker on arm64 hardware with My Machines or a Team Pool. Its decision tree says to contact your enterprise account team for ARM support.

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. It recommends the managed path when you can configure access through these controls.

• 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 Enterprise teams, to private GitHub Enterprise Server, GitLab Enterprise, package registries such as Artifactory or Nexus, private source control APIs, and related webhook traffic.

Cursor then operates the agent infrastructure, while your team controls which repos, secrets and network resources each environment can reach. On the managed path, your part is first-time environment configuration, secrets, repository access and network policy. Cursor manages the host and environment lifecycle after that.

Those four jobs still take work, and Cursor's setup docs call environment setup the most important step to improve cloud agents. The setup guide walks through environment configuration, and network policy sits with the three egress modes in security and network.

Cursor's over-80% figure describes its own customer base, not yours, so it is a weak argument in a design review. It is useful for 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 to the policy or internal service that made it so.

The two self-hosted configurations serve different scales. My Machines is for personal or small-scale workflows on one user's machine. Team Pools are for Enterprise teams that want central ownership of worker hardware, and they require an Enterprise plan.

In practice, the caption's last clause decides it: a My Machines worker must stay online while sessions run. A laptop that sleeps on a train, or reboots overnight for an OS update, drops offline mid-session. For the case Cursor names, a one-off repo whose local state you'd rather not recreate in the cloud, that can be a fair trade. If you want to start a run and walk away, keep the worker on a machine that stays awake.

The per-user, per-repo binding also limits how far My Machines scales. Four people can run four workers, but forty people end up with forty machines that nobody patches centrally.

Around that size, a pool starts to pay for itself. We would weigh service account authentication above 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 on either self-hosted path. A pool also needs a named owner, 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.. Cursor says the main difference is where tool execution happens and who operates that execution environment. Secrets differ too: My Machines use the machine's own credentials, and Team Pools receive dashboard secrets only through Secret sync.

Cursor's own version of this table adds two rows that matter for setup. On managed agents, every environment setting applies, and team, user and environment-scoped secrets reach the machine. On My Machines and Team Pools, only the environment's repository list applies, so everything else, from install and startup commands to network settings, has to be set up on the machine.

The row to slow down on is the second one. Tool calls are where a cloud agent does damage when something goes wrong. Cursor's security page says a Cloud Agent auto-runs terminal commands so it can iterate on tests, and that this creates a data exfiltration risk through prompt injection. On the managed path, those commands run inside an isolated VM that Cursor provisions and manages. On My Machines, tool calls run on a machine that already holds one user's checkout and credentials, and that user keeps it 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. Cursor still runs the agent loop, inference and planning, and your team still reaches 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. from the desktop app, the web and mobile.

Settle what that means before the compliance conversation, because "self-hosted" can be heard as covering the model too. Cursor's help center answers "Is Cursor on-prem now?" with "No." Its docs say the full checkout, build cache and machine-local credentials stay on your machine, but during a run the worker sends Cursor file contents, terminal output, diffs, screenshots and local MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. results. If your rule is that nothing code-adjacent leaves your network, neither My Machines nor a Team Pool meets it.

When a self-hosted run misbehaves, check the worker 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 it is still online. On My Machines the worker has to stay up for the whole session, so rule that out first.