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 narrows “self-hosted” cloud agents to a hybrid architecture: execution can reach private infrastructure and specialized hardware, but planning, inference, and potentially sensitive tool output remain cloud-side. It strengthens the case that environment completeness is central to coding-agent usefulness while making isolation, capacity, recovery, and data-boundary review customer responsibilities.