AI Engineering

Cursor Self-Hosted Machines Make Agent Compute a Placement Decision

Cursor's self-hosted machines move Cloud Agent tool execution onto infrastructure you control, changing how teams draw the boundary around code, secrets, and agent work.

Cloud coding agents have a trust-boundary problem. Useful agents need a real checkout, a shell, package registry access, test databases, internal docs, local MCP servers, and enough credentials to do work. Those things usually live inside the perimeter, while the agent product usually lives outside it.

Cursor's September 2, 2026 self-hosted machines release is an important answer to that split. It does not make Cursor an on-prem product. It makes the placement of agent tool execution explicit.

What Happened

On September 2, 2026, Cursor announced support for self-hosted machines for Cloud Agents. The changelog describes the feature directly: tool execution can now stay on infrastructure you operate, while the agent continues to handle tool calls against that machine. The release includes dynamic pool scheduling, support for running Cloud Agents on existing sandbox providers, and computer-use support on Linux and macOS workers.

The same day, Cloudflare published a changelog entry and a Sandbox SDK tutorial for running Cursor Cloud Agents on Cloudflare via self-hosted machines. In Cloudflare's version of the architecture, each assigned Cursor session runs in its own Cloudflare Container. Cursor keeps the agent loop, inference, and planning. Cloudflare runs the commands, file edits, repository operations, and other tools inside infrastructure the customer controls.

Cursor's documentation makes the boundary more precise. Self-hosted machines move Cloud Agent tool execution to a machine you manage. The user experience still goes through Cursor surfaces such as the desktop app, cursor.com, and mobile. The worker performs file edits, terminal commands, computer-use actions, and local MCP calls.

There are two main operating modes. "My Machines" connects a personal laptop, devbox, VM, or Mac for an individual workflow. "Team Pools" are shared worker pools for teams and enterprises, authenticated with service account API keys and selected as routing targets when starting a Cloud Agent run.

This is not just a convenience toggle. It is a change in deployment shape. Cursor-managed Cloud Agents already provide isolated managed VMs, network controls, private connectivity, secrets, and artifact handling. Self-hosted machines are for cases where those controls are not enough.

Why It Matters

For experienced engineering teams, the hardest question around coding agents is not "can it edit code?" It is "where does the agent run, and what can it touch?"

Agent execution is where the blast radius lives. The model call matters, but the shell matters more. A tool call can read a repository, run a migration script, start a browser, hit an internal API, call a local MCP server, or dump a secret through terminal output. A production-grade agent rollout has to decide where those actions execute, which identity they use, which network paths are reachable, and what evidence is retained afterward.

Before this pattern, teams usually had three awkward choices: run locally on a developer machine, use a vendor-managed cloud VM, or build a custom agent runner. Local execution keeps internal access nearby but is hard to govern. Vendor-managed execution scales better but can violate network, source-control, or compliance constraints. Custom runners give control, but the platform team now owns queueing, authentication, sandboxing, logs, artifacts, worker health, retries, and product integration.

Self-hosted machines split the difference. Cursor still owns the agent product and orchestration surface. Your infrastructure owns the execution plane. That is a better primitive than pretending every team is comfortable putting the full development runtime in a vendor VM.

The Cloudflare integration is notable because it shows this model can be more than a static VM with a long-running daemon. The reference template uses a Worker as the controller, a Durable Object to own the session container, Cloudflare Containers for isolated execution, R2 for optional repository snapshots, and a cron trigger to keep the pool serviced.

The nuance matters: self-hosted execution does not mean no data leaves your network. Cursor's docs say the full checkout, build cache, and machine-local credentials stay on the worker, but the worker still sends the agent the content needed to operate, including file contents, terminal output, diffs, screenshots, local MCP results, and routing metadata. Cloud Agent artifacts may also be uploaded to Cursor-managed storage for pull requests and dashboards.

That means this feature is not a fit for a threat model where no source-derived content can be transmitted to the agent service or model provider. It is a fit for the more common enterprise constraint: code and execution should stay on controlled infrastructure, private services should be reached from inside the network, and agent access should be routed through existing machines, images, credentials, and audit systems.

How It Works

The core Cursor mechanism is a worker process. You install the Cursor CLI on a machine you control, authenticate it, and start a worker. The worker opens a long-lived outbound HTTPS connection to Cursor's backend. Cursor sends agent tool calls across that connection; the worker executes locally and returns results.

That outbound-only shape is important. Cursor does not need inbound access to the worker. The worker reaches Cursor, then uses whatever local access the machine already has: repository credentials, internal package registries, private services, local MCP servers, or specialized hardware.

The operational split looks like this:

Cursor cloud:
  agent loop
  model inference
  planning
  session orchestration
  product UI

Self-hosted worker:
  repository checkout
  shell commands
  file edits
  local MCP servers
  build/test tools
  optional desktop/browser control

For teams, the more interesting mode is Team Pools. A pool is a named routing target. A user starts a Cloud Agent run and selects a self-hosted pool. The request waits until a worker claims it. Once claimed, Cursor forwards activity for that run to that worker. Team Pool workers require a Cursor Enterprise plan and a team service-account API key.

Cloudflare's reference architecture makes the worker lifecycle elastic. The template deploys a Worker, a Durable Object namespace, a container application, an R2 bucket binding, and a cron trigger. The Worker acts as a controller: it lists pending requests for the configured pool, holds Cursor's pending-request stream open between scheduled runs, claims a request, and starts one guest container for that session.

For repository-bound runs, the request includes the repository URL. The container clones or restores that repo into $HOME/workspaces/repo-0, then starts the Cursor worker with that directory as the worker root. The worker derives the repository label from the Git remote, so the template warns against configuring repo= labels by hand. For any-repository runs, the container starts with an empty working directory and no Git remote; the agent or a project hook can clone later.

R2 snapshots are optional. If configured, the template can store a post-clone working tree snapshot for repository-bound starts. A cache miss falls back to a normal Git clone.

The lifecycle is intentionally session-shaped. The template claims a request with a unique worker ID, starts a container, opens the outbound bridge to Cursor, and stops the container after the configured idle timeout. A Durable Object enforces the maximum run lifetime. The Worker itself exposes only health and optional snapshot routes; Cursor remains responsible for the agent loop and session orchestration.

There is a small deployment warning worth taking seriously: Cloudflare's tutorial says a new container image rollout stops running containers. That is normal container-platform behavior, but it matters for long-running agent sessions. Do not deploy worker image changes as casually as a stateless web frontend if active agents are mid-task.

Example

Imagine a platform team that wants coding agents to fix internal developer tooling. The repositories live in GitHub Enterprise Server, dependencies come from a private Artifactory instance, integration tests talk to staging services on a private network, and builds depend on a custom Linux image. Cursor-managed Cloud Agents might be workable with private connectivity, but the team has a written control saying repository checkouts and tool execution must stay inside its cloud account.

A self-hosted pool gives that team a cleaner starting point.

First, create a dedicated Cursor team service account for the worker pool, not a human user's key. Store it in the runtime secret system of the platform that hosts the workers.

Second, build a worker image that matches the team's real build environment. Install the Cursor CLI, language toolchains, package manager configuration, CA roots, browser dependencies if computer use is required, and only the local MCP servers that should be available to agents.

Third, decide how repositories are reached. For a Cloudflare Containers deployment, the template supports GIT_USERNAME and GIT_TOKEN secrets for private repository access. In a mature deployment, prefer short-lived credentials or a narrowly scoped machine identity where possible.

Fourth, define the pool and route only appropriate work to it. A pool named platform-internal should not be a generic dumping ground for every repo. Use separate pools for different network zones, hardware profiles, or approval regimes.

Fifth, lock down output paths. The worker must send file contents, terminal output, diffs, screenshots, and MCP results when the agent needs them. Do not print tokens in build logs. Do not let scripts echo .env files. If artifact uploads are not acceptable, Cursor documents that blocking outbound traffic to the Cloud Agent artifact bucket disables artifact uploads while allowing tool calls to continue.

Sixth, add operations. Watch worker startup failures, pool claim failures, 401 responses from bad service-account keys, container capacity, clone latency, and idle shutdown behavior. If the pool is down, agents become unavailable for the teams that depend on it.

For Cloudflare, the minimum deployment flow is simple enough to reason about:

git clone https://github.com/anysphere/cloudflare-workers.git
cd cloudflare-workers
npm install
npx wrangler r2 bucket create cursor-pool-worker-snapshots
npx wrangler secret put CURSOR_API_KEY
npx wrangler secret put GIT_USERNAME
npx wrangler secret put GIT_TOKEN
npx wrangler deploy

The reference template gives you the integration path. You still own the image, secrets, scaling policy, repository access, network access, monitoring, and production validation.

My Take

This is the right abstraction for where coding agents are going. The industry is slowly separating the agent control plane from the execution plane, because the execution plane is where enterprise requirements become concrete.

The control plane wants product velocity: chat surfaces, mobile access, pull request integration, session state, model selection, planning, and orchestration. The execution plane wants locality: code, credentials, caches, internal networks, GPUs, Macs for iOS builds, local MCP servers, and customer-specific hardening.

Cursor's self-hosted machines are strongest when the concern is execution locality. If your issue is "the agent needs to run tests against services that only my worker can reach," this fits. If your issue is "no source-derived content can be transmitted to Cursor or a model provider," this does not solve it by itself. The model still needs context. The agent still receives outputs.

I also like that Cursor's docs do not pitch self-hosting as the default. Managed Cloud Agents remain the lower-operations path when private connectivity, egress controls, isolated VMs, Privacy Mode, and customer-controlled secrets cover the requirement. Running agent workers is infrastructure. It needs patching, incident response, scaling, observability, and a clear owner.

The Cloudflare example is a good sign because it treats agent execution as an ephemeral cloud workload. One claimed request becomes one isolated container. A Durable Object owns that container. The worker exits after idle. Optional R2 snapshots speed up repository startup without making cache correctness part of the agent contract.

The part I would be strict about is credentials. A self-hosted worker has enough power to run commands inside your network. It should have a purpose-built identity, narrow repository access, narrow package access, bounded network egress, and logs that let you reconstruct what happened.

Conclusion

Cursor's September 2 self-hosted machines release is not just another coding-agent checkbox. It makes agent compute placement a first-class architecture decision.

For teams that can use managed Cloud Agents, staying managed is still the lower-operations path. For teams blocked by perimeter rules, private networks, custom hardware, custom images, or local MCP dependencies, self-hosted machines provide a practical middle ground: Cursor keeps the agent experience and orchestration, while your infrastructure runs the tools.

The action item is to be precise about the boundary. Decide what must stay local, what can be sent back to the agent service, which credentials the worker owns, how runs are isolated, how artifacts are handled, and who operates the pool. With that discipline, self-hosted execution can make cloud coding agents usable in environments where vendor-hosted tool execution was previously a nonstarter.