Cursor is expanding its agent story with generally available self-hosted cloud agents, a deployment option that keeps code, tool execution, and build artifacts inside an organization’s own network while still using Cursor’s orchestration and agent experience.
Cursor’s cloud agents are designed to operate as parallel, autonomous workers: each runs in an isolated virtual machine with a terminal, browser, and full desktop, clones a repo, sets up the environment, writes and tests code, and pushes changes for review—continuing even when the initiating developer is offline. The self-hosted variant keeps that same workflow but relocates the execution environment to infrastructure controlled by the organization.
Why self-hosted agents matter for regulated and complex environments
Cursor positions self-hosting around two recurring constraints: compliance-driven data boundaries and development environments that only exist privately. In regulated enterprises, code, secrets, and build artifacts often cannot leave internal networks. In other cases, critical inputs—like caches, dependencies, and internal endpoints—are only reachable from tightly configured internal machines.
Cursor says teams that previously invested engineering time into maintaining in-house background coding agents are instead adopting its self-hosted option, citing Brex, Money Forward, and Notion as customers using the approach.
Same agent capabilities, deployed on internal infrastructure
Self-hosted cloud agents are intended to mirror Cursor-hosted cloud agents, including:
- Isolated remote environments with dedicated machines per agent session (no sharing), aimed at better parallelization
- Multi-model support, including Composer 2 and other frontier-lab models via Cursor’s agent harnesses
- Plugins for extending agent behavior with skills, MCPs, subagents, rules, and hooks
- Team permissions to manage access and runs across an organization
Cursor also notes planned additions: the ability for self-hosted agents to produce videos, screenshots, and logs, plus remote desktop takeover. The company also points to using these agents to run automations.
How Cursor’s worker model connects without inbound network changes
The key moving piece is a worker process that connects outbound to Cursor over HTTPS—Cursor emphasizes no inbound ports, firewall changes, or VPN tunnels required. When an agent session starts, Cursor’s agent harness handles inference and planning, then sends tool calls to the worker for execution on the organization’s machines. Results are returned to Cursor for the next inference loop.
Each session gets a dedicated worker started with a single command: agent worker start. Workers can be long-lived or single-use, persisting across sessions or tearing down after tasks complete.
For larger rollouts, Cursor provides a Helm chart and Kubernetes operator, including a WorkerDeployment resource to define pool size; the controller handles scaling, rolling updates, and lifecycle management. For non-Kubernetes setups, Cursor offers a fleet management API for utilization monitoring and custom autoscaling.
Self-hosted cloud agents can be enabled in the Cursor Dashboard, with additional details in the documentation.
Source: Cursor
