Cursor has launched Self-Hosted Machines, letting teams run the tool-execution step of its cloud coding agent on machines they control themselves. Only the execution environment moves; the agent loop, reasoning and planning still run on Cursor's cloud, and task kickoff and scheduling remain Cursor's job too.
The connection works the other way around: an enterprise machine installs the Cursor CLI and runs agent worker start, which opens a long-lived outbound HTTPS connection from that machine to Cursor's cloud. Cursor states explicitly that the platform never initiates a connection into a company's network. For security teams, that means a channel that only goes out, never in — no need to open a hole in the firewall for it.
Why Bring Execution Back In-House
Cursor lists three scenarios. First, agents that need direct access to internal source repositories, internal services and databases while they work — a hosted VM simply can't reach them. Second, jobs that need specific hardware, such as a GPU for training or a Mac for building iOS apps. Third, an operating system or build pipeline too heavy to fit into a standard cloud image.
All three of these block large companies specifically. Small and midsize teams have no trouble with hosted sandboxes, but compliance rules at banks, hospitals and large manufacturers often flatly require that code never touch third-party infrastructure — until now, that kind of customer had to lock agents out entirely.
Two Configurations and a List of Partners
Setup comes in two tiers. My Machines attaches a single laptop or VM to an individual account; Pools are named, team- or enterprise-level queues that scale capacity automatically with request volume. The latter is built for dozens or hundreds of people sharing a pool of build machines.
On the sandbox side, Cursor has hooked up a lineup of providers, including AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace and Vercel. Putting these names together says something about how this launch is positioned: Cursor isn't trying to build its own isolated runtime — it's handing that layer to companies already doing it, and holding on to agent scheduling and the model itself. Namespace's offering stands out in one respect: it can spin up a real Mac for every cloud agent session.
Both Linux and Mac workers also expose browser control — once Chrome or Chromium and its dependencies are installed on the machine, an agent can open a page itself to verify a change.
One Number That Makes the Point
Cursor disclosed in its post that more than 60% of the pull requests merged internally were created by cloud agents. That figure appears in an article about enterprise deployment, and the intent is clear: prove you're eating your own cooking before asking customers to hand over their machines.
Looking at the product line, Cursor has spent the past year pushing further into the scheduling layer: first moving agents to the cloud, then fixing startup speed, and now tackling where execution actually happens. The center of competition among coding tools has shifted from completion quality to where the runtime lives — whoever can deliver both a managed experience and code that never leaves the network is the one who gets the enterprise budget.
Sources: Cursor's official blog, CocoLoop, and public documentation from the sandbox providers; the 60% internal merge share, the connection design and the provider list follow Cursor's own statements.