Cursor Self-Hosted Cloud Agents Now Keep Code In-Network

Cursor made self-hosted cloud agents generally available on March 25, letting enterprises run the execution layer for its coding agents inside their own infrastructure while Cursor continues to handle orchestration, inference, planning, and model access. If you want agent-driven code changes without sending your codebase, tool execution, or build artifacts into a vendor-managed runtime, this release changes the deployment options for Cursor’s agent stack.

Execution Architecture

The product split is straightforward. Cursor’s cloud side runs the agent harness, including inference and planning, then sends tool calls to a customer-hosted worker. The worker executes those tool calls on a machine inside your environment and returns results for the next inference round.

This is a control plane / execution plane separation, not full on-prem agent hosting. Model access still runs through Cursor. The execution runtime moves to your network.

Each agent session gets a dedicated worker. Workers can be long-lived or single-use, and the base startup path is agent worker start.

Network and Security Model

The most important implementation detail is the connectivity model. The worker connects outbound to Cursor over HTTPS only, with no inbound ports, no firewall changes, and no VPN tunnels required.

For enterprise teams, that reduces the deployment burden substantially. You can preserve your existing security boundaries, internal network topology, dependency mirrors, caches, and service access patterns, while still using Cursor’s agent UX from the editor, web app, Slack, GitHub, Linear, or API.

Cursor positions this directly around keeping code, tool execution, and build artifacts inside your environment. If your blockers were compliance reviews, internal package registries, private test infrastructure, or network-restricted services, this is the feature that addresses them.

Deployment Surfaces

Cursor supports the same broad entry points as its hosted agent workflows. You can launch self-hosted agents from the editor, web app, Slack, GitHub, Linear, and the API.

The extension model also carries over. Self-hosted cloud agents work with skills, MCPs, subagents, rules, and hooks. If you already use Cursor’s agent customization patterns, the main change is runtime placement, not a new programming model. The distinction between reusable capabilities and local policy still matters, especially if your team already relies on agent skills or is deciding between shared tools and editor-level constraints in Cursor rules.

Kubernetes and Fleet Operations

Cursor is aiming this at large organizations, not one-off workstation installs. For Kubernetes deployments, it provides a Helm chart, a Kubernetes operator, and a WorkerDeployment resource to define pool size, with support for scaling, rolling updates, and lifecycle management.

For non-Kubernetes environments, there is a fleet management API for utilization monitoring and custom autoscaling.

Cursor’s clearest scale target is support for organizations running thousands of workers. That places the product closer to internal CI or ephemeral build-worker infrastructure than to a single remote dev box.

Capability	Self-hosted cloud agents
Worker connectivity	Outbound HTTPS only
Inbound networking	None required
Session isolation	Dedicated worker per session
K8s support	Helm chart, operator, WorkerDeployment
Non-K8s ops	Fleet management API
Target scale	Thousands of workers

What Changed From Earlier Cursor Agent Releases

Earlier Cursor cloud-agent launches used Cursor-managed sandboxes and isolated VMs. This release keeps the same product surface and moves execution into customer infrastructure.

That matters if you were evaluating agentic coding against internal repos, test harnesses, staging systems, or private services. Before this launch, the hosted sandbox model limited adoption for teams with strict network controls. After this launch, the agent can operate where your engineers and service accounts already operate.

The release also ties directly into Cursor’s broader agent stack from the past month. Self-hosted agents support Composer 2, which Cursor recently introduced with Standard pricing at $0.50 per million input tokens and $2.50 per million output tokens, and Fast pricing at $1.50 per million input tokens and $7.50 per million output tokens. If you are comparing coding-agent platforms, this adds a meaningful enterprise deployment differentiator alongside the model and workflow differences covered in our look at AI coding assistants.

Enterprise Adoption Signals

Cursor named Brex, Money Forward, and Notion as customers using self-hosted cloud agents.

The most concrete deployment number came from Money Forward, which said it is building a workflow for nearly 1,000 engineers to create pull requests directly from Slack using self-hosted agents. Brex emphasized access to internal infrastructure for test suites and tools. Notion highlighted security and avoiding duplicate operational stacks.

Those examples point to the real use case: agents that can touch internal systems safely enough to handle build, test, and PR workflows end to end. This is the same broader shift behind current work on stateful agents and more serious agent evaluation, where the hard problem is no longer text generation alone, but controlled action inside production environments.

Near-Term Product Direction

Cursor says self-hosted agents will soon add videos, screenshots, and logs for demos, remote desktop takeover, and support for automations. Those additions would close some of the remaining gap between self-hosted execution and the richer remote-computer workflows Cursor has been building elsewhere.

If you run engineering in a regulated or network-segmented environment, the immediate takeaway is simple: evaluate Cursor agents as internal workers, not external sandboxes. The key design decision is whether you are comfortable with Cursor retaining the cloud control plane while your code execution stays in-network.