Cursor has expanded its self-hosted cloud agent infrastructure, adding dynamically scheduled worker pools and support for running agent workloads across cloud and infrastructure platforms.
The update allows development teams to manage the machines that execute tool calls from Cursor’s cloud agents while continuing to start and manage agent sessions through Cursor. The company made self-hosted cloud agents generally available on March 25, 2026.
Under the architecture, Cursor continues to run the agent loop, inference, and planning in its cloud. File edits, terminal commands, repository operations, computer-use tools, and local Model Context Protocol (MCP) servers can run on machines managed by the customer.
A worker running on the customer’s infrastructure connects to Cursor through a long-lived outbound HTTPS connection. Cursor then sends tool calls to that worker for execution, with the results returned to the service for subsequent inference.
Cursor does not initiate inbound connections into the customer’s network. The working copy of a repository, build caches, secrets, and tool execution remain in the customer environment, although the results of tool calls are sent back to Cursor as part of the agent loop.
Cursor lists access to network-restricted resources, specialised hardware, custom operating systems, and existing build pipelines among the reasons teams might use self-hosted machines instead of its managed environments. The setup allows agent tools to reach development resources available only inside an organisation’s network.
GitHub added self-hosted runner support to Copilot coding agent in October 2025, allowing the agent’s development environment to run on customer-managed GitHub Actions infrastructure. GitHub cited access to internal resources, including packages unavailable on the public internet, as one use case for self-hosted runners.
CI/CD-style worker pools
The September update adds dynamically scheduled team pools, where workers can serve requests from developers across a team or enterprise rather than being assigned to one individual machine or repository.
Requests wait in a named pool until an available worker claims them. Separate pools can be configured for different execution environments, including GPU machines or Macs used for iOS development.
A controller can monitor demand and start additional workers when a pool does not have enough idle capacity. Cursor also provides deployment options for Kubernetes and Google Cloud Run. Its Kubernetes operator manages warm capacity, rolling worker updates, and token rotation, while its Cloud Run deployment uses a custom autoscaler driven by the Cloud Agents API.
Comparable scheduling models are already used by CI/CD systems. GitLab Runner continuously polls for jobs and can create cloud instances when additional capacity is required, while GitHub Actions supports autoscaling self-hosted runners and routing jobs according to labels such as operating system, processor architecture, or GPU availability.
Cursor uses worker pools to route agent workloads instead. A GPU pool can handle tasks requiring accelerator hardware, while an iOS pool can route work to Macs. Once a worker claims a request, it executes terminal, file, browser, and other tool operations generated by the agent.
Traditional CI/CD runners execute jobs defined by a workflow or pipeline. Cursor’s workers execute tool calls generated during an agent session, while inference and planning continue in Cursor’s cloud.
Cursor’s pools are not tied to specific code repositories. Development teams can identify a required pool when submitting a request, allowing available workers within that pool to handle tasks from different repositories.
Cursor has also added support for hibernating idle workers. Organisations can snapshot and stop an idle machine, then restore the environment if an agent receives a follow-up request within a configured reconnect period.
Customers operating self-hosted machines remain responsible for the cost and management of their machines, containers, or clusters. Cursor-managed Cloud Agents include the execution infrastructure as part of the service.
Customers using self-hosted deployments are responsible for worker images, infrastructure, secrets, scaling policies, and production validation. By comparison, Cursor manages VM provisioning, isolation, snapshots, and capacity for its hosted environments.
Security moves into the worker environment
Self-hosting does not move Cursor’s entire agent stack into the customer environment. Cursor continues to handle orchestration, model access, inference, and planning, while customer-operated workers execute terminal commands, code changes, browser actions, local MCP servers, and requests to internal services.
Some information therefore still passes between the worker and Cursor. Tool results are returned through the outbound connection for subsequent inference, and Cursor can receive artefacts generated during Cloud Agent sessions for display in pull requests and its dashboard.
Cursor allows administrators to block the endpoint used for artefact uploads. Its documentation says doing so prevents those artefacts from appearing in pull requests or the dashboard but does not stop the agent from continuing to make tool calls and receive results.
Running workers internally leaves the organisation responsible for securing machines that can access source code, credentials, build systems, and internal network resources. GitHub warns that a compromised Actions runner can expose repository secrets and authentication tokens available to a workflow.
Cursor similarly states that customers are responsible for the secrets and production configuration used by their self-hosted workers, which can execute commands and access internal services through credentials available in their environment.
Cursor says self-hosted workers can run across infrastructure from AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, and Vercel.
Cloudflare’s implementation places each assigned Cursor session in an isolated container. Cursor retains inference, planning, and the agent loop, while commands, file changes, and repository operations execute inside the customer’s Cloudflare environment.
The worker can therefore use infrastructure and network access configured by the customer while Cursor continues to handle the agent’s orchestration and inference.
Agents run outside the editor
Cursor’s worker pools also allow agent execution to operate separately from an individual developer workstation. Shared pools can accept requests across an organisation, with centrally managed workers claiming sessions according to the selected execution environment.
Agent sessions also do not have to start inside the editor. Cursor allows teams to specify worker pools for Cloud Agents triggered through GitHub, Slack, and Linear, while automations configured through the Cloud Agents dashboard can also target particular pools.
GitHub uses a comparable background model for Copilot coding agent. The agent runs asynchronously in a GitHub Actions-powered development environment, where it can modify code, run builds and tests, and prepare a pull request for developer review. Self-hosted Actions runners can place that execution environment on infrastructure managed by the organisation.
The Cursor update also adds computer-use support for self-hosted Linux workers alongside Mac machines. Once the required desktop packages and Chrome or Chromium are installed, an agent can interact with a browser, take screenshots, and use other computer-control functions.
Developers can view the agent’s desktop while it is working or take control of the environment through Cursor. Mac workers can also provide environments for workloads that require Apple hardware, including iOS development.
Cursor also supports self-hosted machines for workloads that require GPU systems, existing build environments, or other infrastructure that differs from its managed virtual machines.
Cursor-hosted virtual machines remain the default environment for its cloud agents. Teams can use self-hosted machines when they require company-controlled infrastructure, internal service access, specialised hardware, or development environments that differ from Cursor’s managed VMs.
(Photo by Compagnons)
See also: Should AI coding agents test their own code?
Want to dive deeper into the tools and frameworks shaping modern development? Check out the AI & Big Data Expo, taking place in Amsterdam, California, and London. Explore cutting-edge sessions on machine learning, data pipelines, and next-gen AI applications. The event is part of TechEx and co-located with other leading technology events. Click here for more information.
Developer Tech News is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.
