Choose where Cloud Agents run
Cursor-hosted Cloud Agents run each agent in an isolated cloud VM with managed lifecycle, saved environments, artifact capture, and dashboard controls for secrets and network access.
Self-hosted paths run tool calls on hardware you control through My Machines or Self-Hosted Pool. The agent loop still runs in Cursor's cloud.
Self-hosted or Cursor-hosted: which is right for you?
Cursor-hosted cloud agents are sufficient for over 80% of our customers. Leverage this decision tree to evaluate what works best for your organization.
Do written policies require repository data and agent compute to stay inside your perimeter?
Usually required by compliance or security policy, not just a team preference.
Self-hosted
perimeter constraint
Do agents need in-network services that Tailscale, PrivateLink, and egress allowlists cannot cover?
Most private networks work with Cursor-hosted agents via Tailscale, PrivateLink, or egress allowlists.
Self-hosted
network reach
Do you need a custom OS, special hardware, or persistent local disk for a very large repo?
Cursor-hosted agents run on Ubuntu VMs. Use a Dockerfile to customize tooling. If ARM is required, talk to your enterprise account team.
Self-hosted
hardware / disk
Cursor-hosted Cloud Agents
No infrastructure to run · elastic concurrency · the full feature surface
Quick comparison
| Option | Choose it when | What you manage |
|---|---|---|
| Cursor-managed Cloud Agents | You want Cursor to manage VM provisioning, isolation, snapshots, startup, artifacts, capacity, and environment deployment after setup. This is the recommended path for most teams. | First-time environment configuration, secrets, repository access, and network policy. Cursor manages the host and environment lifecycle after that. |
| My Machines | You want a personal laptop, devbox, or remote VM to execute tool calls for a specific user and repo. | The machine, worker process, local checkout, credentials, uptime, disk, network access, and keeping the machine in a clean working state. |
| Self-Hosted Pool | You need an org-managed worker fleet with service account auth, pool routing, labels, Kubernetes, autoscaling, or dedicated hardware. | Hosts, images, VM resets, capacity, autoscaling, worker updates, monitoring, secrets, network access, and incident response. |
Start with managed Cloud Agents
Managed Cloud Agents are usually the lowest-operations way to give agents secure access to code and internal systems.
Use the managed path when you can configure access through:
- 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, package registries such as Artifactory or Nexus, 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.
When My Machines fits
My Machines works best for personal or small-scale workflows where a specific user already has a machine with the right checkout, tools, credentials, and private network access.
Use it for:
- A developer's devbox or remote workstation.
- A one-off repo that depends on local state you do not want to recreate in a cloud environment.
- A quick test before building a centrally managed worker pool.
My Machines is not an org-wide fleet system. Each worker belongs to the user who started it, targets the repo where it was started, and must stay online while sessions run. You also own cleanup: wiping state, refreshing the checkout, repairing dependencies, and keeping the machine ready for the next run.
When Self-Hosted Pool fits
Self-Hosted Pool is for Enterprise teams that want centralized ownership of worker hardware or need to route work to specific fleets.
Use a pool when you need:
- Service account authentication instead of per-user worker login.
- Kubernetes, autoscaling, labels, and fleet monitoring.
- Dedicated hardware profiles, such as GPU workers or high-memory build machines.
- Company-managed hosts that execute all terminal commands, file edits, browser actions, and local MCP servers.
The tradeoff is operational ownership. Your team runs the fleet, keeps enough workers available, patches and flashes images, resets VMs between runs, manages capacity, rotates credentials, monitors health, and handles host failures. If your primary requirement is private network access, try managed Cloud Agents with network controls, Tailscale, or private connectivity first.
Security model differences
All three options support Privacy Mode and controlled secrets. The main difference is where tool execution happens and who operates that execution environment.
| Question | Managed Cloud Agents | My Machines | Self-Hosted Pool |
|---|---|---|---|
| Where does the agent loop run? | Cursor cloud | Cursor cloud | Cursor cloud |
| Where do tool calls run? | Cursor-managed isolated VM | Your machine | Your worker |
| Who manages host and environment lifecycle? | Cursor, after first-time environment configuration | You | Your team |
| How do agents reach private resources? | Environment networking, allowlists, Tailscale or similar clients, and private connectivity for supported source control paths | Your machine's existing network | Your worker fleet's network |
| Best operational fit | Most teams and repos | Individual users and specific machines | Centralized enterprise fleets |