Estimated reading time: 5 minutes · Last updated:
Cursor has extended its self-hosted Cloud Agents so development teams can run agent-generated tool calls on machines they control while keeping orchestration and inference in Cursor’s cloud. The company made self-hosted cloud agents generally available on 25 March 2026 and this update adds dynamically scheduled team pools, hibernation for idle workers, and deployment options including a Kubernetes operator and Google Cloud Run. Muhammad Zulhusni, as first reported by Developer Tech News, described how workers connect out to Cursor over long-lived HTTPS and execute file edits, terminal commands, browser actions and local MCP servers inside customer infrastructure.
Key takeaways
- General availability: Cursor made self-hosted cloud agents generally available on 25 March 2026.
- Scheduling and pools: Cursor's September update also added dynamically scheduled team pools that dispatch agent tool calls to available workers, with specific pools designated for GPU machines and for Macs.
- Execution model: Cursor keeps inference, planning and the agent loop in its cloud while customer-run workers execute tool calls and return results over an outbound HTTPS connection.
- Platform support: Cursor lists supported infrastructures that include AWS Lambda and Cloudflare, alongside Coder, Daytona, E2B, Modal, Namespace and Vercel.
- Comparable moves: GitHub added self-hosted runner support for Copilot coding agent in October 2025 to let environments run on customer-managed Actions infrastructure.
Table of contents
How Cursor separates orchestration from execution
Cursor’s design keeps orchestration, model access, inference and planning inside its cloud while delegating tool execution to machines managed by customers. A worker runs in the customer environment and connects to Cursor over a long-lived outbound HTTPS link; Cursor sends tool calls to that worker and receives results back for subsequent inference and planning.
That split means sensitive assets — a working repository copy, build caches, credentials and internal services — can remain behind a company’s firewall while the agent’s decision-making happens in Cursor’s service. Administrators can block the endpoint for artefact uploads so items produced by a session do not appear in pull requests or the dashboard, though tool-call results still return to Cursor for inference.
The architecture supports local Model Context Protocol (MCP) servers and other browser or terminal interactions that must run inside a customer network. Because Cursor does not initiate inbound connections, the vendor says the model loop never opens the customer perimeter; only an outbound worker connection carries results and artefacts back to Cursor.
CI/CD-style pools, deployment options and hibernation
In September, Cursor introduced dynamically scheduled team pools: requests sit in a named pool until a worker claims them, and teams can assign pools to particular execution environments such as GPU-capable machines or Macs used for iOS work. After a worker claims a request, it carries out the session’s generated operations — terminal commands, file actions, browser interactions and other tool calls.
Cursor provides multiple deployment choices: a Kubernetes operator that manages warm capacity, rolling updates and token rotation, and a Cloud Run deployment that uses a custom autoscaler driven by the Cloud Agents API. The company also documents options for autoscaling and for controllers that start additional workers when a pool lacks idle capacity.
Cursor’s pool model borrows scheduling ideas from CI/CD systems but differs in what gets executed. Traditional runners run pipeline-defined jobs; Cursor’s workers execute tool calls produced dynamically during an interactive agent session, and pools are not tied to specific code repositories. The update also adds hibernation support so idle machines can be snapshotted and stopped, then restored if follow-up activity arrives within a configured reconnect period.
Security and operational responsibilities for customer-run workers
Operating self-hosted workers shifts machine, image and secrets management to customers. Cursor states that customers remain responsible for worker images, infrastructure, scaling policies and production validation while Cursor manages provisioning and snapshots for its hosted VMs. The worker’s ability to execute commands and access internal services means credentials available in that environment determine what the agent can reach.
GitHub's guidance warns that a compromised Actions runner can expose repository secrets and tokens accessible to a workflow. Cursor echoes that risk, warning that self-hosted workers must be secured because they can reach source code, build systems and resources protected by network restrictions.
For managed platforms, Cursor lists a range of supported infrastructures including AWS Lambda and Cloudflare. Cloudflare’s implementation places each assigned Cursor session in an isolated container so commands, file changes and repository operations run inside the customer’s Cloudflare environment while Cursor retains inference and orchestration in its cloud.
| System | Scheduler model | Inference & planning | Execution location | Repository binding |
|---|---|---|---|---|
| Cursor self-hosted cloud agents | Dynamically scheduled team pools | Runs in Cursor cloud | Customer-managed workers (outbound HTTPS) | Not tied to specific repositories |
| GitLab Runner | Continuous polling and instance creation for jobs | N/A (runner executes pipeline jobs) | Runner or cloud instances | Jobs are defined by repository pipelines |
| GitHub Copilot (with self-hosted runners) | Actions-based routing and autoscaling (self-hosted added Oct 2025) | Agent runs asynchronously via Actions environment | Customer-managed Actions runners | Environment tied to workflow or action context |
Upside and downside for teams adopting self-hosted agents
The case for
- Enables access to internal-only resources, existing build pipelines and specialised hardware such as GPUs or Macs.
- Centralised pools let organisations share accelerated or specialised environments across teams rather than tying them to individual developer workstations.
- Kubernetes operator and Cloud Run deployment options simplify autoscaling and lifecycle management in environments that already use those platforms.
The case against
- Self-hosting increases operational overhead: customers must manage images, scaling policies, secrets and production validation.
- A compromised worker risks exposing repository secrets, build caches or credentials available in that host environment.
- Teams relying on Cursor’s cloud for inference still transmit tool-call results and artefacts over the outbound connection, which requires policy review and controls.
What to be careful about
- A breached self-hosted worker can expose repository secrets and authentication tokens present on that host, mirroring known Actions-runner risks.
- Misconfigured hibernation or snapshot restore processes could reintroduce stale credentials or insecure state into a restored worker.
- Relying on an outbound connection for artefact uploads requires careful access controls and a plan for disabling uploads where policy forbids them.
The bottom line
Cursor’s extension of self-hosted cloud agents gives engineering organisations a practical way to run agent-driven operations on infrastructure they control while relying on Cursor for orchestration and model access. The team-pool model and deployment choices such as a Kubernetes operator and Cloud Run aim to scale shared, specialised execution environments; hibernation reduces resource waste. The trade-off is operational: customers must secure and manage worker images, secrets and scaling, and they should validate snapshot and restore procedures before moving sensitive workloads onto self-hosted workers.
What to watch
- Watch for published third-party security assessments of Cursor’s self-hosted worker model; no date has been set.
- Watch for case studies from enterprises that adopt pooled GPU or Mac workers to see operational templates and cost signals; no date has been set.
- Watch for additional platform integrations from Cursor or the listed providers; no date has been set.
Frequently asked questions
What stays inside my network when I run Cursor self-hosted workers?
The working copy of repositories, build caches, secrets and tool execution can remain on machines you run; Cursor keeps inference, planning and the agent loop in its cloud and workers return tool-call results over an outbound HTTPS connection.
Can I run agent workloads on Macs and GPU servers?
Yes. The update adds pools for GPUs and supports Mac workers for iOS and other Apple-dependent tasks; Cursor also supports self-hosted Linux workers for computer-control features once desktop packages and Chrome/Chromium are installed.
How do Cursor pools differ from CI/CD runners?
CI/CD runners execute predefined pipeline jobs and often poll for work; Cursor’s pools route tool calls generated dynamically during agent sessions, are not bound to a single repository, and let available workers claim requests from across a team.
Related reading
