# Cursor self-hosted machines move agents on-prem _Cursor now lets cloud agents run on customer-managed machine pools, keeping execution inside your network while inference stays in Cursor cloud._ **Published:** 2026-09-02 **Source:** https://www.startuphub.ai/ai-news/artificial-intelligence/2026/cursor-self-hosted-machines-move-agents-on-prem --- [Cursor Blog](https://cursor.com/blog/self-hosted-machines) says Cursor self-hosted machines let cloud agents run on dynamically scheduled pools inside your network while still starting from Cursor. The Sep 2 post by Jack Pertschuk positions control over execution location as the next bottleneck as agents do more real work. Cursor says cloud agents now create more than 60% of pull requests merged internally. ## How self-hosted Cursor workers actually run Tool execution moves to your machine while the agent loop, inference and planning stay in the Cursor cloud. You install the Cursor CLI and run agent worker start, which opens a long-lived outbound HTTPS connection that Cursor never initiates inbound. When a session starts, the harness sends tool calls to that dedicated worker, which holds the working copy, edits files, runs commands and returns outputs that may contain code. Think of it like a remote hands technician: your hands touch the repo, Cursor does the thinking elsewhere. ## Why it matters, and what it still doesn't fix Teams choose this when agents need direct access to internal services, GPUs or Macs for iOS builds, or custom OS and build pipelines that don't fit a standard Cloud Agent build. [Cloudflare](/startups/cloudflare) director Meagan Gamache, who leads Developer Platforms, frames isolated self-hosted execution as the foundation for trusted agent development. Supported sandbox providers now include AWS Lambda, [Cloudflare](/startups/cloudflare), Coder, [Daytona](https://www.startuphub.ai/startups/daytona), E2B, Modal, Namespace and Vercel, so teams can reuse sandboxes they already run. AWS Lambda senior product manager Ayush Kulkarni describes Lambda MicroVMs launching near-instantly from snapshots and suspending when idle as the compute layer for this model. Pools serve any repository and scale with demand via a controller that watches the queue and runs your spawn script, so you don't pre-size the fleet. Idle workers can reset, preserve the workspace for follow-ups, or hibernate to a snapshot and restore with the same ID if a follow-up arrives in the reconnect window. Linux workers now support computer use alongside Macs when Chrome or Chromium is installed, letting agents click, screenshot and drive a browser you can watch. What isn't fixed is the data boundary: tool outputs and transcripts flow back to Cursor for inference and may be processed and stored, so sensitive code still leaves the network. The operational win is subtle but real. One pool can serve many repos and ride existing infrastructure instead of standing up a parallel agent farm. If agents keep writing most merged code, where they run stops being a preference and starts being a procurement and audit requirement. --- Original analysis from [startuphub.ai](https://www.startuphub.ai), the #1 AI startup directory.