Cursor Cloud Agents Can Now Run on Self-Hosted Machines

Cursor Cloud Agents can now run on machines that a team manages, including dynamically scaling pools inside its own network. The agent is still started and managed from Cursor, but the execution environment can sit next to internal services, source control, custom hardware, or a build pipeline that is difficult to package as a standard Cloud Agent environment. (Cursor on X; Cursor announcement)

This is an infrastructure boundary change, not a separate local agent product. Cursor says the execution environment moves while the agent loop, inference, and planning remain in the Cursor cloud. (Cursor announcement)

Why teams might use self-hosted workers

Cursor lists three main use cases:

• Internal network access: let agent tools reach source control, repositories, and services that are not exposed to a hosted worker.
• Specialized hardware: run on GPUs, Macs for iOS development, Kubernetes infrastructure, sandboxes, or managed virtual machines.
• Unusual build environments: use an operating system or pipeline that is difficult to reproduce in a normal Cloud Agent build.

Cursor-hosted environments remain the default. In those environments, each session runs on a dedicated VM in Cursor's cloud with dependencies, network controls, per-agent isolation, secret redaction, egress controls, and signed commits. (Cursor announcement)

The agent loop stays in Cursor's cloud

With Self-Hosted Machines, only the worker that executes tools moves into the team's environment. Cursor continues to perform inference and planning, then sends tool calls to the worker. The worker returns results for the next round of inference. (Cursor announcement)

That split is useful for teams that need network locality without giving up Cursor's cloud-agent workflow. It also defines an important data boundary: Cursor says tool outputs flow back to its cloud for inference and may contain code, while agent transcripts may be processed and stored by Cursor. Self-hosting therefore changes where commands run; it does not mean that all agent data stays inside the team's network. (Cursor announcement)

Register a machine or create a pool

Cursor's setup path uses a worker process:

1. Install the Cursor CLI on the machine that should execute agent tools.
2. Run agent worker start.
3. Let the worker establish its long-lived outbound HTTPS connection to Cursor.
4. Start a Cloud Agent and assign it to the connected machine or pool.

Cursor says it never initiates a connection into the team's network. A My Machines configuration connects one laptop or VM to an account and is aimed at personal workflows. A Pool is a named queue of workers that can serve a team or enterprise. (Cursor announcement)

Pools can scale with demand. A controller watches the request queue and uses a team-supplied spawn script to start machines as work arrives; capacity can fall again as workers disconnect. Pools are not tied to one repository, so an available worker can serve requests for multiple repositories. (Cursor announcement)

Supported sandbox providers

Cursor says Self-Hosted Machines can work with several providers so teams do not have to build a sandbox layer from scratch. The announcement lists:

• AWS Lambda
• Cloudflare
• Coder
• Daytona
• E2B
• Modal
• Namespace
• Vercel

The AWS Lambda example uses MicroVMs in the team's AWS account. Cursor says a machine can launch from a snapshot, suspend while idle, and resume with its state. (Cursor announcement)

Computer use on Linux and Mac

The update also adds computer use on Linux alongside Mac workers. With the required dependencies, including Chrome or Chromium, an agent can click, take screenshots, and control a browser. Cursor says a user can watch the desktop or take control directly from Cursor. (Cursor announcement)

The announcement does not publish a new pricing tier or promise that every Cloud Agent feature behaves identically on every provider. Teams evaluating the feature should confirm the current documentation, worker requirements, and their data-retention obligations before connecting production infrastructure. (Cursor announcement)

What changes for engineering teams

Self-hosted execution gives a team a way to bring Cloud Agents closer to the systems they already operate:

1. Keep sensitive build dependencies or internal services behind the team's network boundary.
2. Use a worker pool instead of leaving a fixed fleet running.
3. Give agents access to specialized machines when a standard hosted VM is not enough.
4. Continue starting and monitoring the work through Cursor.

The trade-off is equally clear: tool results still travel to Cursor for the agent's next inference step. Self-Hosted Machines are best understood as managed execution locality for Cursor Cloud Agents, not as an offline or fully isolated deployment. (Cursor announcement)

Sources

• Cursor on X, “You can now run Cursor cloud agents on your infrastructure,” September 2, 2026: https://x.com/cursor_ai/status/2095257412781396114
• Cursor, “Run cloud agents on machines you manage”: https://cursor.com/blog/self-hosted-machines