Cursor Launches Self-Hosted Machines, Routing Cloud Agent Execution to Customer-Controlled Infrastructure
Cursor released Self-Hosted Machines on September 2, 2026, giving enterprise development teams the option to run Cloud Agent tool execution on their own servers or cloud sandboxes instead of Cursor's hosted environment. Codebase files, build outputs, and secrets stay inside the customer's network during agent sessions.
What shipped
Cursor's Cloud Agents now support two execution paths. The default path still runs sessions on Cursor-hosted VMs with per-agent isolation, secret redaction, and egress controls. The new path routes tool execution to a machine the customer controls.
To register a machine, teams install the Cursor CLI and run agent worker start, which opens a long-lived outbound HTTPS connection to Cursor's cloud. Tool calls travel from Cursor's agent harness to the worker for local execution. Results return to Cursor for the next inference round. Cursor initiates no inbound connections into the customer's network, per the Cursor blog.
Two worker configurations are available. "My Machines" connects a single laptop or VM to an individual account, suited to personal workflows. Pools are named queues of workers that a team or enterprise can share. A pool controller watches the request queue and starts machines automatically as demand arrives, using a spawn script the team supplies. Idle workers disconnect after a configurable timeout, and hibernation lets teams snapshot a running machine so a follow-up session restores quickly rather than rebuilding its workspace from scratch.
Eight sandbox providers integrate out of the box: AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, and Vercel. Teams can route agent sessions against any repository through a single pool without creating per-repo queues.
Why it matters
The core shift is about where code touches infrastructure. In Cursor's standard hosted model, tool execution happens in Cursor's cloud, which means code edits, build outputs, and any secrets the agent accesses pass through Cursor's systems. Self-Hosted Machines moves that execution surface into the customer's network. Only inference and planning remain in the Cursor cloud.
That distinction matters most for three groups: teams whose security policies require source code to stay on-premises, engineering environments that need agent access to internal services not reachable from a third-party cloud, and teams running builds on specialized hardware such as GPU instances or Mac workers for iOS development.
Cursor reported in the September 2 blog post that Cloud Agents already create more than 60 percent of the pull requests the company merges internally. That usage pattern is extending to large enterprise customers. As agent sessions grow longer and touch more sensitive tooling, execution location becomes a procurement and security question, not just a performance consideration.
GitHub Copilot and JetBrains AI have not shipped an equivalent on-premises agent execution mode as of this writing. That gap gives Cursor an early position for enterprise accounts where data-residency requirements block cloud AI coding tools from reaching production workflows.
What to watch next
Cursor has not announced FedRAMP or SOC 2 certification for Self-Hosted Machines. Those certifications are the most common procurement blockers for regulated industries, including federal contractors and financial services firms. Whether Cursor pursues those audits will determine how far Self-Hosted Machines can reach into federal and regulated enterprise accounts. A competitive response from GitHub Copilot or JetBrains AI on on-premises agent execution is also worth watching in the months ahead.
Sources
- Run cloud agents on machines you manage: Cursor, September 2, 2026
- Self-Hosted Machines changelog: Cursor changelog, September 2, 2026
- Cursor lets companies run cloud coding agent workloads on their own infrastructure: Developer Tech, September 2026
