Cursor adds self-hosted cloud agent worker pools

Estimated reading time: 5 minutes · Last updated: 4 September 2026

Cursor expanded its Cloud Agents offering to let companies run agent tool execution on machines they control while Cursor keeps inference, planning and orchestration in its cloud. Muhammad Zulhusni reported for Developer Tech News that self-hosted cloud agents reached general availability on 25 March 2026 and that a September update adds dynamically scheduled team pools, Kubernetes and Google Cloud Run deployment options, and hibernation for idle workers. Under the model, a long-lived outbound HTTPS connection carries tool-call results back to Cursor while the working copy, build caches and secrets remain on customer infrastructure.

How Cursor’s self-hosted model splits work between cloud and customer machines

Cursor keeps inference, planning and the agent loop in its cloud while customers run tool execution on machines they manage. A worker on the customer side connects to Cursor using a long-lived outbound HTTPS connection; Cursor sends tool calls to that worker and receives results back for subsequent inference. This design prevents Cursor from initiating inbound connections into a customer network.

The working copy of a repository, build caches, secrets and the actual execution of terminal commands, file edits, browser interactions and local Model Context Protocol (MCP) servers remain in the customer environment. Administrators who need to stop artefacts from leaving their environment can block the endpoint used for artefact uploads, which prevents those artefacts from appearing in pull requests and the Cursor dashboard while still allowing the agent to make tool calls.

CI/CD-style worker pools: dynamic scheduling, hibernation and deployment options

The September update introduces dynamically scheduled team pools so workers serve requests from across a team or enterprise rather than being tied to one developer or repository. Requests queue in a named pool until an available worker claims them; teams can configure separate pools for environments such as GPUs or Macs for iOS builds. Cursor’s controller can monitor demand and start additional workers when idle capacity is insufficient.

Cursor provides a Kubernetes operator that manages warm capacity, rolling worker updates and token rotation, and a Google Cloud Run deployment that uses a custom autoscaler driven by the Cloud Agents API. The update also adds support for hibernating idle workers: organisations can snapshot and stop an idle machine and restore it if an agent issues a follow-up request within a configured reconnect period.

Security trade-offs and customer responsibilities

Running workers inside an organisation shifts several operational and security responsibilities to the customer. Cursor’s documentation states customers are responsible for worker images, infrastructure, secrets, scaling policies and production validation, while Cursor continues to manage VM provisioning, isolation, snapshots and capacity for its hosted VMs. That division means machines with access to source code, credentials and internal services must be secured by the customer.

The risk is concrete: GitHub warns that a compromised Actions runner can expose repository secrets and authentication tokens available to a workflow, and Cursor explicitly notes customers must protect secrets and production configuration used by self-hosted workers. Organisations can reduce exposure by isolating workers, controlling who can deploy worker images and blocking the artefact-upload endpoint when required.

When teams should choose self-hosted workers over Cursor-hosted VMs

Teams should choose self-hosted machines when they need access to network-restricted resources, specialised hardware or existing build pipelines unavailable to Cursor’s managed VMs. Cursor cites access to internal packages, specialised accelerator hardware and custom operating systems as reasons to run workers on customer infrastructure. Examples in the update include GPU pools for accelerator tasks and Mac workers for iOS development.

Cursor-hosted virtual machines remain the default environment for Cloud Agents; self-hosted deployments trade Cursor-managed execution for customer control and cost responsibility. That trade-off suits organisations that cannot expose internal services externally or that must run tools against resources only reachable from inside their network.

Where adoption can accelerate — and what could slow it

The bottom line

Cursor’s self-hosted Cloud Agents offer a middle path: customers keep sensitive data, build caches and specialised hardware inside their networks while Cursor retains model access and orchestration. The September update’s team pools, Kubernetes operator and Cloud Run support lower integration friction for cloud-native shops, but they also transfer concrete responsibilities — worker images, secrets and production validation — to the customer. Teams that need internal-only access or specialised accelerators will find the trade-off worthwhile; others will likely stick with Cursor-hosted VMs to avoid the operational work.

What to watch

• watch for case studies or blog posts that show teams using Cursor’s team pools in production; no date has been set.
• watch for Cursor documentation updates that publish technical references for the Kubernetes operator and the Cloud Run autoscaler; no date has been set.