Cursor Self-Hosted Agents Keep Tools Inside Your Network

Cursor's September 2, 2026 change moves the security boundary and the infrastructure bill together: your team can keep agent tool execution on machines it controls, but it now owns those workers. The model, planning, and agent loop still run in Cursor's cloud.

The change is a split runtime

A Cursor Cloud Agent has two halves. The agent loop decides what to do next and calls the model. Tool execution is the part that edits files, runs terminal commands, opens a browser, talks to a local MCP server, and reaches internal services.

Cursor Self-Hosted Machines separates those halves. Cursor keeps the loop, inference, planning, interface, and session orchestration. A worker you manage executes the tools.

That worker can be a laptop, a VM, a Mac, a Kubernetes pod, or a sandbox from an integration partner. It opens an outbound HTTPS connection to Cursor, receives tool calls, runs them locally, and returns the results. Cursor doesn't need an inbound port or a public IP on the worker.

Here is the operating split.

Cursor offers two worker shapes. My Machines attaches a machine to one person's account and suits a devbox or a narrow personal workflow. Team Pools are named queues for Enterprise teams. A request waits in a pool until an available worker claims it, and each pool worker handles one Cloud Agent session at a time.

This is not an on-premise Cursor model. It is a split runtime with a customer-owned execution half. That distinction decides whether the feature meets your policy.

What stays inside, and what still leaves

The full checkout, build cache, and machine-local credentials stay on your worker. Commands, repository operations, builds, and calls to internal services happen there too. That can remove the need to copy an entire repository into a vendor-managed execution VM.

The agent still needs context to make decisions. During a run, the worker sends Cursor the file contents the agent needs, terminal output, diffs, screenshots, local MCP results, and routing metadata. Screenshots, videos, and log references can also be uploaded to Cursor-managed artifact storage so they appear in pull requests and the dashboard.

You can block the artifact host without stopping the agent, but those artifacts then disappear from the pull request and dashboard. Privacy Mode also applies, which means code sent from the worker isn't used for training by Cursor or its model providers. It does not make the session offline.

That is the first business consequence. A security review can now approve the execution location separately from model processing, but it still has to approve both.

Who can use it, and what changes for them

An enterprise backend team with internal services

A backend team may need a private package registry, a staging database, and service endpoints that aren't reachable from a managed VM. A Team Pool can sit on the same controlled network and run the build without opening an inbound route from Cursor.

The payoff is access control, not automatic privacy. The platform team can use its existing network policy and secret store, while the security team reviews exactly which results cross the outbound connection.

An iOS team tied to Macs

Cursor-managed Cloud Agents run on Ubuntu VMs. A team that needs Mac hardware for iOS work can register Macs as workers, add the required computer-use permissions, and let an agent click, type, take screenshots, or drive the browser on that machine.

The payoff is that the remote agent can use the same hardware class as the build. The cost is familiar to anyone who runs a Mac build fleet: image drift, permissions, uptime, cleanup, and replacement remain your problem.

A platform team with bursty agent demand

A platform team can put Cloudflare Containers behind a Team Pool. The reference template starts one isolated container per claimed session, uses a Durable Object to own that container, and can cache repository snapshots in R2.

The pool survives when no workers are connected, so capacity can scale to zero. When work returns, the controller claims the request and starts a container. The payoff is usage-shaped compute instead of a permanently warm fleet.

An individual builder with a stateful devbox

My Machines fits a builder whose project depends on local tools or state that would be tedious to recreate. Multiple agents can share that machine, which is convenient for a personal box and a warning for sensitive work.

The payoff is setup speed. The risk is cross-run residue, because Cursor is not wiping and rebuilding your laptop between sessions. You own the working directory, credentials, process cleanup, and machine health.

A runnable Cloudflare setup

The Cloudflare route is useful because it makes the new ownership boundary visible. It requires Cursor Enterprise, a team service-account key with agent scope, a Cloudflare Workers Paid account with Containers and R2, Node.js 20 or later, and Docker.

1. 1

   Register a Team Pool

   Install the Cursor CLI, confirm it runs, then connect a temporary local worker so the pool appears in Cursor.

   curl https://cursor.com/install -fsS | bash
   agent --version
   export CURSOR_API_KEY="<team service-account API key>"
   CURSOR_API_KEY="$CURSOR_API_KEY" agent worker --pool cloudflare-test start

   Stop that worker with Ctrl+C after the pool appears, then run unset CURSOR_API_KEY. Keep the local worker stopped while testing Cloudflare so it cannot claim the request first.

2. 2

   Deploy Cursor's reference template

   Clone the template, install it, sign in to Cloudflare, and create the optional snapshot bucket.

   git clone https://github.com/anysphere/cloudflare-workers.git
   cd cloudflare-workers
   npm install
   npx wrangler login
   npx wrangler r2 bucket create cursor-pool-worker-snapshots

3. 3

   Store the credentials

   Put the Cursor service-account key in Worker secrets. Add Git credentials only when the containers need private repositories.

   npx wrangler secret put CURSOR_API_KEY
   npx wrangler secret put GIT_USERNAME
   npx wrangler secret put GIT_TOKEN

   A personal Cursor API key does not work for a Team Pool. This is the setup error most likely to look like an infrastructure failure because the controller returns 401.

4. 4

   Set the pool and capacity

   In wrangler.jsonc, change CURSOR_POOL to cloudflare-test. Set containers[].max_instances to the most simultaneous sessions you are prepared to run, not the number of developers on the team.

   The reference file defaults to max_instances 10 and a standard-1 container with 0.5 vCPU, 4 GiB of memory, and 8 GB of disk. Real builds may need a larger shape.

5. 5

   Deploy and watch the first run

   Deploy, then keep the controller and container views open while you start a Cloud Agent and select the self-hosted pool.

   npx wrangler deploy
   npx wrangler tail
   npx wrangler containers list

   The initial scheduled controller run can take up to five minutes to begin. A claimed session that does not start usually points to container capacity, repository cloning, or Git credentials.

The cost moved, it did not disappear

Cursor-managed Cloud Agents include the execution infrastructure. Self-Hosted Machines still use the selected model at Cursor's pricing, then add your worker bill. Team Pools also require an Enterprise contract, whose price is custom.

Cloudflare shows how the extra line behaves. Its Containers product sits on the $5 monthly Workers Paid plan. That includes 25 GiB-hours of memory, 375 vCPU-minutes, and 200 GB-hours of disk. Beyond that, memory costs $0.0000025 per GiB-second, active CPU costs $0.000020 per vCPU-second, and provisioned disk costs $0.00000007 per GB-second.

Take the reference template's standard-1 shape and model 100 sessions that each work for one hour, use the full available CPU while active, then sit through the template's five-minute idle window. After the included usage, the container math is about $12 for the month:

$5 plan + $3.15 CPU + $3.675 memory + $0.168 disk = $11.993

That is an infrastructure illustration, not the total Cursor bill. It excludes Worker and Durable Object usage, logs, egress, R2, the Enterprise contract, model usage, and the people who maintain the fleet. It also assumes the smallest template shape is enough. A compile-heavy repository may force a larger container.

The expensive decision is often not the per-second rate. It is the warm-capacity policy. Cursor's generic pool worker defaults to a 3,600-second reconnect window, while the Cloudflare template shortens that to 300 seconds. A longer window makes follow-up prompts faster and keeps provisioned memory and disk billing. A shorter window saves idle spend and adds more cold starts.

Capacity is yours too. The template ships with room for 10 concurrent containers. The next request waits or fails to start when the chosen capacity, account limit, or underlying host is unavailable. Cursor can route work to a pool, but it cannot create capacity you did not provision.

Isolation follows the same rule. The Cloudflare template gives each session its own container. A personal machine can run multiple agents on one host. If your policy requires a fresh VM, a wiped disk, tenant separation, or a clean secret boundary after every run, you have to build and verify that behavior.

Patching becomes an operating calendar. Your team owns the base image, Cursor CLI, build tools, certificates, dependencies, and rollout. On Cloudflare, deploying a new container image stops running containers, so an update has to wait for active sessions or accept the interruption.

What to do now

Act this week if a Cloud Agent needs custom hardware, a custom image, or tool access that managed networking cannot provide. Start with a narrow pool and a low-risk repository. Keep model processing and returned tool data in the security review, because the execution move does not remove them.

Wait if your only requirement is access to private source control or an internal service. Cursor recommends trying managed environments, network controls, Tailscale, AWS PrivateLink, or Cloudflare Tunnel before taking on a worker fleet. Those routes leave host lifecycle and isolation with Cursor.

You are unaffected if managed Cloud Agents already pass policy and reproduce your build. Self-hosting adds no new model capability. It changes execution location and operational ownership.

The Monday move is concrete: pick one representative repository, write down which code, secrets, tool outputs, and artifacts may cross the boundary, then run the same build on a managed agent and a tightly capped self-hosted pool. Record queue wait, container-hours, accepted changes, cleanup failures, and the time spent maintaining the image. Approve the fleet only if the control requirement is worth that second bill.

Get the next operator-grade AI workflow breakdown in the newsletter.