Cursor lets cloud agents run on machines managed by the company itself

Cursor has announced a feature called "Self-Hosted Machines" that allows its Cloud Agents to run coding tasks on machines managed by the customer, inside their own network, instead of exclusively on Cursor's infrastructure. The core idea is to separate two layers: on one side, the "agent loop" (inference and planning), which continues to run in Cursor's cloud; on the other, the tool execution environment (where files are edited, commands are run and the repository is accessed), which can now be moved to the team's own machines, whether managed VMs, sandboxes, Kubernetes or specific hardware such as GPUs or Macs.

According to the article, this separation addresses three typical scenarios in which Cursor's default model (a dedicated VM inside Cursor's cloud, with per-agent isolation, secret redaction, network egress controls and signed commits) falls short: when the agent needs direct access to internal services and to source control within the corporate network; when specialized hardware is required (GPUs, or Macs for iOS development); or when the organization's operating system or build pipeline is too idiosyncratic to be packaged as a standard "Cloud Agent build".

The technical mechanism relies on a component called a "worker": a piece that is installed through Cursor's CLI (the agent worker start command) and that opens a persistent outbound HTTPS connection to Cursor's cloud. The article stresses, as a security detail, that Cursor never initiates an inbound connection into the customer's network; it is the customer's machine that connects outward. When a session starts, Cursor's agent engine handles inference and plans the steps, but sends the tool calls (running commands, editing files, etc.) to the corresponding worker, which executes them locally and returns the result for the next round of inference. The article also clarifies that, although execution happens on the customer's machine, tool outputs —which may contain code— travel back to Cursor for inference, and that agent transcripts may be processed and stored by Cursor, a relevant nuance for any team evaluating this option for compliance or confidentiality reasons.

Workers can be configured in two ways. "My Machines" connects a single laptop or VM to a personal account, designed for individual workflows. "Pools" is a named queue of workers that can serve a team or an entire company: capacity grows when requests arrive and shrinks when workers disconnect, so that infrastructure scales with real developer demand without anyone having to decide in advance how many machines to keep running. A controller watches the request queue and uses a "spawn script" provided by the team itself to bring machines up when needed. If no worker is available, the request simply waits for capacity.

To avoid unnecessary spending on machines left running without activity, a "hibernation" mechanism is introduced: if a machine goes idle, a snapshot can be taken and the machine stopped; if a follow-up task arrives within a reconnection window, the snapshot is restored and a worker starts up again with the same identifier, recovering state without having to rebuild the working environment from scratch (a process that, according to the article, can take several minutes if the machine is simply released without a snapshot). In addition, pools are not tied to a specific repository: a request only needs to identify the pool, and any available worker can serve it, which allows a single pool to serve multiple repositories.

As for the ecosystem, Cursor has not built this sandboxing layer from scratch, but instead leans on several infrastructure partners: AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace and Vercel. The article includes statements from representatives of several of these companies (AWS Lambda, Cloudflare, Vercel, Modal and Namespace), each highlighting how their sandbox or virtual machine platform fits this model: for example, it is mentioned that with Lambda MicroVMs developers can run agents inside their own AWS account, with near-instant boot from a snapshot, suspension on idle and resumption with full state; or that Namespace can spin up a real Mac (on Apple silicon) for each cloud agent session, which is necessary to build iOS or macOS apps, something that cannot be done without Apple hardware.

Another technical addition is that Linux workers now support "computer use" in addition to Mac workers: if the machine has the necessary dependencies installed, including Chrome or Chromium, the agent can click, take screenshots and control the browser, and the user can watch that desktop or take control directly from Cursor.

The article places all of this in a business context: it states that cloud agents already generate more than 60% of the pull requests the company itself merges internally, and that they are taking on a growing share of software development work at many of the large enterprises Cursor works with. It is a figure worth reading with caution: it refers to Cursor's internal use on its own code, not to an independent measurement or a number generalizable to all its customers, and the article provides no further breakdown of methodology. Even so, it serves as an explicit justification for why the company is investing in giving more control over execution infrastructure: if agents are going to take on an ever-larger portion of coding work, where and under what conditions they run becomes a corporate infrastructure decision, not just a product convenience.

Taken together, the feature fits into a broader trend among coding agent providers: keeping the intelligence (model, planning, orchestration) centralized in the provider's cloud, while offering flexibility over where the actual execution of the code happens, in order to satisfy security requirements, regulatory compliance, access to specialized hardware or to internal systems that would otherwise force exposing secrets or repositories to an external environment. The balance Cursor proposes —local execution, but transcripts and tool outputs that still pass through its servers for inference— is the point any team evaluating this option will probably want to examine more closely before adopting it at scale.