Cursor quietly shipped one of its most significant infrastructure updates in March 2026: Cloud Agents. The feature itself is not entirely new β the concept of background agents running in isolated environments has been in development for months β but the general availability of self-hosted variants marks a meaningful shift in how development teams can deploy AI-assisted automation at scale.
This post explains what Cloud Agents are, what the two self-hosted deployment modes (My Machines and Self-Hosted Pool) actually mean, and how to think about each option depending on your context.
What Are Cloud Agents?
At their core, Cursor Cloud Agents are autonomous coding agents that run in isolated virtual machines. Each agent gets its own environment β a terminal, a browser, and a full desktop β where it clones your repository, installs dependencies, writes and tests code, and pushes changes for review. Critically, they operate asynchronously: you can kick off a task and walk away. The agent keeps working whether or not you are at your desk.
The architecture is split into two distinct responsibilities. Cursor's cloud handles inference and planning β the AI reasoning layer that decides what to do next. The worker handles execution β actually running commands, reading files, and interacting with your environment. These two layers communicate via tool calls: the agent sends an instruction like read_file("auth.py"), the worker executes it locally, and the result flows back for the next reasoning step.
This separation is what makes self-hosting possible without losing the intelligence of the model. Your code never leaves your environment. Cursor's cloud only sees the metadata of what tool was called and what it returned β not your source code in full.
Cursor-Hosted vs. Self-Hosted
By default, when you use Cloud Agents, Cursor spins up a virtual machine on its own infrastructure. This is the simplest path β zero setup, works immediately. The trade-off is that your code, secrets, and build artifacts leave your environment and run on Cursor's servers.
Self-hosted agents reverse this. You supply the execution environment β your own machine, a VM in your private network, or a Kubernetes cluster β and Cursor's orchestration layer connects to it. Your codebase stays inside your infrastructure throughout the entire session.
For many teams, this is not optional. Regulated industries, financial services companies, and organizations with mature internal dependency caches often cannot route code through external systems. Self-hosted Cloud Agents were built specifically for these constraints.
My Machines: For Individual Developers
My Machines is the self-hosted option for individual use. The premise is simple: your laptop, devbox, or a personal remote VM becomes the execution environment for an agent session. You run a single command β agent worker start β and your machine registers itself as a worker. From that point, any Cloud Agent session you initiate routes its tool calls to your local environment.
The practical benefit is that the agent inherits everything your machine already has: your local dependencies, your SSH keys, your access to internal APIs, your cached build artifacts. There is no cold-start problem, no environment parity issue. The agent works exactly as you would, because it is working inside your environment.
Workers can be configured as long-lived β staying registered across multiple sessions β or single-use, tearing down once a task completes. For most individual developers, long-lived workers running on a devbox or always-on VM are the natural choice.
Self-Hosted Pool: For Teams and Enterprise
Self-Hosted Pool extends the same concept to organizational scale. Instead of a single machine, you deploy and manage a pool of workers β a fleet of execution environments that your team's agent sessions draw from. Each session still gets its own dedicated worker; the pool simply ensures there are enough workers available to handle concurrent demand.
For teams running on Kubernetes, Cursor provides a Helm chart and a Kubernetes operator. You define a WorkerDeployment resource specifying your desired pool size, and the controller manages the rest: scaling, rolling updates, and worker lifecycle. For non-Kubernetes environments, a fleet management API exposes utilization metrics and hooks for building custom autoscaling logic on any infrastructure.
The operational model is outbound-only by design. Workers initiate an outbound HTTPS connection to Cursor's control plane β no inbound ports need to be opened, no VPN tunnels need to be configured. This is a deliberate security decision that significantly reduces the overhead of getting self-hosted agents approved by enterprise IT and security teams.
Choosing Between the Two
The distinction is primarily one of scale and ownership. My Machines is appropriate when a single developer wants to use their own environment as the execution context β useful for accessing local tools, internal services, or simply avoiding uploading a sensitive codebase to external servers. Self-Hosted Pool is appropriate when an organization wants to provide this capability to an entire team, with centralized management, controlled scaling, and team-level permissions.
Both modes deliver the same core guarantee: your source code, secrets, and build outputs remain within infrastructure you control. The difference lies in who manages the workers and how many are running at any given time.
What This Means in Practice
The practical implication of Cloud Agents β particularly the self-hosted variant β is that background automation becomes a first-class part of how a team builds software. Agents can run in parallel on separate tasks: one upgrading a dependency, another generating test coverage, a third triaging a bug report. They work asynchronously, submit pull requests, and produce artifacts β screenshots, logs, videos β for human review.
For teams that have been cautious about AI tooling due to data residency or compliance concerns, self-hosted Cloud Agents remove the primary blocker. The code never moves. Only the intelligence does.