Cursor now lets customers run its cloud coding agents on infrastructure the customer owns and controls, rather than exclusively on Cursor’s own virtual machines. The feature, called Self-Hosted Machines, keeps the agent’s reasoning and planning inside Cursor’s cloud while shifting the part that touches code (cloning repositories, editing files, running builds) onto a machine sitting inside the customer’s network.
That split matters more than it sounds. For a year, the pitch for cloud coding agents assumed customers would tolerate code and credentials leaving their perimeter in exchange for not managing infrastructure. Cursor’s own numbers suggest that trade stopped being optional: the company says cloud agents now generate more than 60 percent of the pull requests merged internally, and that at its biggest enterprise accounts an expanding slice of engineering now flows through these agents. At that volume, security and platform teams stop treating agent access as a pilot exception and start treating it as a standing infrastructure decision, with the same scrutiny given to CI runners or build farms.
Cursor is not the first vendor to hear this. Enterprise buyers have said for months that the holdup on agentic coding tools was rarely the model’s competence and almost always where the code, secrets, and internal service access physically lived during execution. Self-Hosted Machines is Cursor conceding that point directly: the product change is not a smarter agent, it is an admission that the location of execution was the actual blocker, and that no amount of benchmark improvement was going to fix a data-residency objection.
Mechanically, a customer installs the Cursor CLI on a machine or VM and runs a worker process that opens a long-lived outbound connection to Cursor’s cloud. Cursor’s agent harness still handles inference and planning; it sends tool calls (edit this file, run this command) to the worker, which executes them locally and returns results. Cursor says it never initiates an inbound connection into the customer’s network, though what the tools return, code included, still travels back to Cursor to feed the next inference round, where it may be processed and kept. That is a narrower privacy boundary than “nothing leaves the network,” and teams evaluating the feature for regulated workloads should read that distinction closely rather than assume full isolation.
Workers can be registered individually for personal use or grouped into pools, a named queue of machines that scales up as requests arrive and scales down after workers disconnect. Cursor has also partnered with AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, and Vercel so pools can run on infrastructure teams already operate, rather than requiring a custom sandbox layer. Pools also now support computer-use browser control on Linux machines in addition to Mac, and hibernation lets an idle machine snapshot and stop instead of staying billed while waiting for a follow-up task.
For engineering leaders currently blocked from deploying cloud coding agents by a security or compliance review, Self-Hosted Machines removes the main objection: code execution can now happen inside infrastructure the customer already audits, on the sandbox provider they already trust. Teams should still confirm exactly what leaves the network during inference before treating this as full data isolation.
Cursor detailed Self-Hosted Machines in a post on its own company blog.
