Cursor is expanding its self-hosted cloud agent infrastructure, giving development teams more control over the machines that actually execute AI-generated coding tasks. The latest update adds dynamically scheduled worker pools and broader support for running agent workloads across different cloud and infrastructure environments, while Cursor continues to handle orchestration, inference and planning in its own cloud.
The change is particularly relevant for organisations that want to use AI coding agents but cannot move all of their development activity into a vendor-managed environment. By separating the AI reasoning layer from the execution layer, Cursor is trying to give companies a middle ground: developers can continue starting and managing Cloud Agent sessions through Cursor, while code changes, terminal commands, repository operations and other sensitive actions happen on infrastructure controlled by the customer.
Cursor Keeps the Agent Brain in the Cloud, but Execution Can Stay Inside the Company
Cursor made self-hosted Cloud Agents generally available on 25 March 2026. Under this architecture, the core agent loop remains in Cursor's cloud, where the service handles model access, inference, task planning and orchestration. The actual tool calls generated by the agent, however, can be executed on customer-managed machines.
Those local actions can include editing files, running terminal commands, interacting with repositories, using computer-control tools and connecting to local Model Context Protocol, or MCP, servers. This means an organisation can allow the AI agent to work with development resources that may not be accessible from the public internet, while keeping the underlying working environment inside its own infrastructure.
The design does not amount to a fully on-premise deployment of Cursor's AI stack. The intelligence layer still lives in Cursor's environment, but the system can delegate execution to a worker running inside the customer's network. That distinction is important because it gives organisations more control over infrastructure without completely removing Cursor from the AI workflow.
The Worker Connects Outbound Rather Than Opening the Network Inbound
Security is a major part of this architecture. A worker running on the customer's infrastructure creates a long-lived outbound HTTPS connection to Cursor, and Cursor uses that connection to send tool calls for execution. The results of those actions are then returned to Cursor so the model can continue reasoning about what to do next.
Cursor does not initiate inbound connections into the customer's network. That can simplify firewall and network-security requirements because organisations do not need to expose development machines directly to the internet just so the agent can reach them.
At the same time, some information still needs to flow back to Cursor. Tool-call results are returned as part of the agent loop, and generated artefacts may also be uploaded for display in pull requests or the Cursor dashboard. Organisations therefore still need to understand what information leaves the environment and how that fits with their own security and data-governance requirements.
Source Code, Secrets and Build Environments Can Remain Under Customer Control
One of the strongest reasons to use self-hosted workers is that sensitive development resources can remain inside the organisation. The working copy of the repository, build caches, credentials, secrets and execution environment can all stay on infrastructure managed by the customer.
This can be valuable for companies that work with tightly controlled source code, proprietary build systems or internal services that are not exposed publicly. It can also help teams that already have mature development infrastructure and do not want to reproduce that environment inside a vendor-managed virtual machine.
For example, an agent might need access to an internal package repository, a private API, a protected database schema or a build system available only through the corporate network. A self-hosted worker can access those resources in the same way an internal developer machine or CI runner would, while the agent itself continues receiving instructions from Cursor.
Why Some Teams May Prefer Self-Hosted Workers
Cursor lists several reasons organisations might choose customer-managed execution rather than its hosted Cloud Agent environments. These include access to network-restricted services, specialised hardware, custom operating systems and existing build pipelines.
The use case becomes even stronger when the organisation has unusual infrastructure requirements. A development team working on machine-learning software may need GPU systems, while an iOS team may require Apple hardware. Other teams may rely on internal build images or custom system configurations that would be inconvenient to reproduce on a generic cloud virtual machine.
Self-hosting allows the company to reuse those environments rather than adapting its workflows to fit Cursor's managed infrastructure. The trade-off is that the organisation becomes responsible for operating and securing those machines itself.
Dynamic Worker Pools Bring CI/CD-Style Scheduling to AI Agents
The September update adds one of the more important operational changes: dynamically scheduled team worker pools. Instead of tying one worker to a particular developer or repository, organisations can create named pools of workers that serve requests from across a team or enterprise.
When a developer launches an agent task, the request can be placed into a selected pool and wait until an available worker claims it. This is similar in spirit to how CI/CD platforms schedule jobs across groups of runners, although Cursor's workers are handling AI-generated tool operations rather than predefined pipeline jobs.
Different pools can be created for different purposes. A company might have one pool for standard Linux development, another for GPU-heavy workloads and another made up of Macs for iOS development. Developers can then route an agent request to the execution environment that matches the task.
A GPU Pool and an iOS Pool Can Serve Different Types of Work
The ability to divide infrastructure into specialised pools gives development teams much more flexibility. A machine-learning task requiring accelerator hardware could be sent to a GPU pool, while an iOS build or test job could be routed to a group of Mac workers.
Once a worker claims a request, it can perform the operations generated by the agent, including terminal commands, file changes, browser interactions and other development tasks. The reasoning about what should happen next still comes from Cursor's cloud, but the actual execution takes place on the selected worker.
This separation could help larger organisations avoid wasting expensive infrastructure. Instead of dedicating one high-end GPU or Mac to a single developer, those machines can become shared capacity that multiple agent sessions use as needed.
Autoscaling Means Workers Can Be Added as Demand Increases
Cursor is also supporting automated scaling for these worker pools. A controller can monitor demand and start additional workers when there are not enough idle machines available to handle queued requests.
The company provides deployment options for environments including Kubernetes and Google Cloud Run. Its Kubernetes operator can manage warm capacity, worker updates and token rotation, while the Cloud Run deployment uses a custom autoscaler connected to the Cloud Agents API.
This model should feel familiar to teams already operating modern CI/CD infrastructure. Rather than maintaining a fixed number of always-on workers regardless of demand, organisations can increase capacity when agent activity rises and reduce it again when workloads fall.
The Model Is Similar to CI/CD, but the Workload Is Different
The comparison with CI/CD runners is useful, but there is an important difference. Traditional systems such as GitHub Actions or GitLab Runner generally execute jobs already defined in a workflow file or pipeline configuration. The sequence of tasks is known before execution begins.
Cursor's workers are more dynamic. They execute tool calls generated during an ongoing agent session, where the next command may depend on the result of the previous one. The AI might inspect a repository, decide to modify a file, run a test, analyse the error, make another change and then continue iterating.
That makes the workload less predictable than a conventional CI pipeline. The worker is not simply executing a static script; it is participating in a loop where Cursor's AI continually decides what should happen next.
Worker Pools Are Not Limited to a Single Repository
Another useful aspect of the design is that worker pools are not permanently tied to specific code repositories. Developers can specify which pool a request requires, and any available worker in that pool can claim the task regardless of which repository is involved.
This creates a shared infrastructure model that is more suitable for larger development organisations. Instead of configuring separate workers for every project, teams can maintain a set of approved execution environments and reuse them across many repositories.
That could simplify governance as well. An enterprise might maintain one tightly controlled production-like worker image, another environment for experimental development and a third for specialised hardware, rather than allowing every team to create its own configuration.
Idle Workers Can Be Hibernated Instead of Running Continuously
Cursor has also added support for hibernating idle workers. When a machine is not being used, the organisation can snapshot the environment and stop the instance rather than paying for it to remain active indefinitely.
If the agent receives a follow-up request within a configured reconnect period, the environment can be restored and the session can continue. This is especially useful for expensive machines such as GPU instances or Macs, where maintaining idle capacity can quickly become costly.
The feature gives companies another way to balance responsiveness against infrastructure cost. Keeping some workers warm provides faster execution, while hibernation can reduce waste when demand is unpredictable.
Self-Hosting Transfers More Responsibility to the Customer
The flexibility of self-hosted execution comes with additional operational responsibility. Customers need to manage their own worker images, machines, containers or clusters, as well as scaling policies, secrets, production configuration and validation.
Cursor-managed Cloud Agents remove much of that burden because Cursor handles the execution infrastructure itself. Its hosted environments include areas such as virtual-machine provisioning, isolation, snapshots and capacity management.
The self-hosted model therefore makes the most sense for organisations that already have the engineering capability to operate development infrastructure securely. Smaller teams without that expertise may still find the managed Cloud Agent environment simpler and more practical.
Security Now Depends Heavily on the Worker Environment
Moving execution inside the customer's infrastructure also changes where much of the security responsibility sits. A self-hosted worker may have access to source code, credentials, internal services, package repositories and build systems, which means compromising that worker could potentially expose highly sensitive resources.
This is not unique to Cursor. GitHub has similarly warned organisations that compromised self-hosted Actions runners can expose repository secrets and authentication tokens available during a workflow. Any system capable of running code inside a trusted development environment needs to be treated as a privileged component.
Cursor places responsibility for worker secrets and production configuration on the customer. Organisations therefore need to think carefully about access controls, network segmentation, credential scope, image hardening, monitoring and how much authority an AI agent should receive inside each environment.
Not Every Tool Result Necessarily Stays Inside the Network
The fact that tool execution happens locally does not mean that all related information remains local. Because Cursor's cloud is still responsible for inference and planning, tool results need to travel back through the outbound connection so the model can determine what to do next.
Cursor can also receive artefacts generated during Cloud Agent sessions for display within pull requests and its dashboard. Administrators can block the endpoint used for these artefact uploads if organisational policy requires it.
Doing so prevents those artefacts from appearing in the dashboard or pull-request interface, but it does not stop the agent itself from continuing to execute tool calls and receive results. This gives administrators some control over how much session output is surfaced through Cursor's collaboration features.
Multiple Infrastructure Providers Can Host Cursor Workers
Cursor says self-hosted workers can operate across infrastructure provided by services including AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace and Vercel. This gives organisations considerable flexibility in choosing where and how workers are deployed.
Cloudflare's implementation, for example, places each assigned Cursor session inside an isolated container. Cursor remains responsible for the agent loop, inference and planning, while commands, file operations and repository work execute inside the customer's Cloudflare environment.
This approach shows how Cursor is trying to separate the AI control plane from the execution environment. The company can provide the coding agent experience without requiring every organisation to run the actual development workload on Cursor-owned machines.
The Approach Echoes What GitHub Has Already Done With Copilot
Cursor is not alone in exploring customer-managed execution for coding agents. GitHub introduced self-hosted runner support for its Copilot coding agent in October 2025, allowing the agent's development environment to run on infrastructure managed through GitHub Actions.
One of GitHub's stated reasons for doing this was access to internal resources, including private packages and services that are not available from the public internet. That is essentially the same enterprise problem Cursor is now addressing with its own self-hosted worker architecture.
The comparison shows how AI coding platforms are beginning to inherit many of the architectural patterns already common in CI/CD. Companies want the convenience of a cloud-managed control plane while retaining direct control over the environments where sensitive code is executed.
Cloud Coding Agents Are Moving Beyond the Developer's Laptop
The worker-pool model also shows how AI coding agents are becoming less dependent on an individual developer workstation. A developer no longer needs to keep a local machine running while an agent works through a long task.
Instead, shared infrastructure can accept agent sessions from developers across an organisation. Centrally managed workers can then claim those requests based on the environment selected for the task.
This makes AI coding agents more suitable for asynchronous workflows. A developer could assign a task, move on to something else and return later to review the resulting code changes, tests or pull request.
Agent Sessions Can Start From GitHub, Slack and Linear
Cloud Agent sessions do not have to begin inside Cursor's editor either. Teams can route agents to specific worker pools when sessions are triggered through GitHub, Slack or Linear, while automations created through the Cloud Agents dashboard can also target selected pools.
This expands the idea of the coding agent from an editor feature into a broader development-service layer. A task could originate from an issue tracker, a pull request or a team conversation and then execute independently on shared infrastructure.
GitHub uses a similar background model with Copilot coding agent. Its agent can work asynchronously inside an Actions-powered environment, make code changes, run builds and tests, and prepare a pull request for a developer to review.
Computer-Use Support Expands What Self-Hosted Agents Can Do
Cursor's update also adds computer-use capabilities for self-hosted Linux workers, joining existing support for Mac environments. With the required desktop packages and Chrome or Chromium installed, the agent can interact with a browser, take screenshots and perform other computer-control actions.
Developers can observe the agent's desktop while it is working and can take control of the environment when necessary. This is useful for tasks that cannot be completed entirely through a terminal or API and require interaction with graphical applications or browser-based development tools.
Mac workers are particularly useful for workloads requiring Apple hardware, such as iOS development. Combined with GPU support and custom operating environments, this makes self-hosted workers suitable for a broader range of development scenarios than generic Linux cloud VMs alone.
The Bigger Shift Is Toward AI Development Infrastructure
Cursor's worker-pool model highlights a broader evolution in AI-assisted software development. Coding assistants started as tools that suggested individual lines or functions inside an editor. They are now becoming autonomous development systems capable of working for extended periods, running commands, editing repositories, using browsers and interacting with internal infrastructure.
That shift changes the infrastructure requirements dramatically. Once an AI agent can execute meaningful work independently, organisations need to think about scheduling, isolation, credentials, monitoring, scaling and network access in much the same way they already manage CI/CD systems.
The difference is that agent behaviour is dynamic rather than fully predefined. This makes governance even more important because an AI system may decide which tools to call based on intermediate results instead of simply following a fixed workflow.
Hosted and Self-Hosted Environments Will Likely Coexist
Cursor's own hosted virtual machines remain the default environment for Cloud Agents, and for many teams that will probably remain the simplest option. The company handles infrastructure, isolation and capacity, allowing developers to focus on the coding task rather than worker management.
Self-hosting becomes more attractive when a company has requirements that the managed environment cannot easily satisfy. Internal network access, specialised hardware, custom build systems, strict security controls or unusual operating environments are all situations where customer-managed execution can provide meaningful advantages.
The two models therefore serve different needs rather than one replacing the other. Smaller teams may favour convenience, while larger enterprises may prioritise control and integration with existing infrastructure.
Final Thoughts
Cursor's expansion of self-hosted Cloud Agents shows how quickly AI coding tools are evolving from editor assistants into infrastructure platforms. The new dynamically scheduled worker pools allow companies to run agent-generated commands on their own machines while Cursor continues handling planning, inference and orchestration in the cloud.
For enterprise development teams, that creates a useful compromise. Sensitive repositories, credentials, build tools and internal network resources can remain inside the company's environment, while developers still benefit from Cursor's agent interface and cloud-based AI reasoning. Specialised pools for GPUs, Macs or custom development environments also make the architecture flexible enough for workloads that would be difficult to support through generic hosted VMs.
The trade-off is that greater control brings greater responsibility. Companies choosing self-hosted workers must secure the machines, manage credentials, design scaling policies and understand exactly what information is still exchanged with Cursor during the agent loop.
As AI coding agents become more autonomous, these infrastructure questions will become increasingly important. The future of AI-assisted development may not simply be about which coding model is smartest, but also about where that model's actions are allowed to run, what resources it can access and how organisations maintain control while the agent works on their behalf.
Comments 0