Run cloud agents on machines you manage
Cursor cloud agents can now execute tools on machines and elastic pools inside your network while Cursor retains planning and inference. This unlocks internal access and custom hardware, not full self-hosting.
Cursor’s **Self-Hosted Machines** move repository access, file edits, and commands onto customer-managed workers. A worker opens outbound HTTPS to Cursor, receives tool calls, and returns results; pools can scale from a queue and serve multiple repositories.
Use this when agents need internal services, private source control, GPUs, Macs, Kubernetes, or unusual build pipelines. Linux workers now support **computer use**, and idle machines can reset, preserve a workspace, or resume from a hibernated snapshot.
Cursor’s **Self-Hosted Machines** move repository access, file edits, and commands onto customer-managed workers. A worker opens outbound HTTPS to Cursor, receives tool calls, and returns results; pools can scale from a queue and serve multiple repositories. Use this when agents need internal services, private source control, GPUs, Macs, Kubernetes, or unusual build pipelines. Linux workers now support **computer use**, and idle machines can reset, preserve a workspace, or resume from a hibernated snapshot. Only execution moves. **Inference, planning, and the agent loop remain in Cursor’s cloud**, while tool output can include code and transcripts may be processed or stored there. Teams still need to evaluate that boundary, worker isolation, capacity controls, and recovery behavior.
This expands Cursor Cloud Agents into environments that managed sandboxes may not reach—private services, GPUs, Macs, Kubernetes, and custom build systems—without moving the agent loop out of Cursor’s cloud. It therefore changes execution control more than data residency: teams gain worker and workspace lifecycle choices but still must assess tool-output exposure, isolation, capacity, and recovery.