Cursor Cloud Agents can now execute tools in customer-controlled infrastructure using Cloudflare, Self-Hosted Machines, and an official Workers template.
That sentence needs an important clarification: this doesn’t mean Cursor has become fully self-hosted.
It means something more interesting for enterprise teams.
Cursor still runs the agent loop, inference, planning, orchestration, and product experience. Cloudflare runs the part that normally makes platform and security teams uncomfortable: commands, file edits, repository operations, builds, browser actions, and local tools within customer-controlled infrastructure.
That’s the real news.
Over the past year, much of the conversation about code agents got stuck on models, IDE integrations, benchmarks, and whether agents are already “good enough” to trust. The more durable enterprise question is different:
Where does the agent actually run?
Cloudflare’s changelog from September 2, 2026 gives a concrete architecture to that question.
What did Cloudflare publish for Cursor Cloud Agents?
Cloudflare published an official route to run Cursor Cloud Agents via Cursor Self-Hosted Machines on Cloudflare Containers.
The Cloudflare Sandbox tutorial describes a deployable template based on Workers, Durable Objects, Cloudflare Containers, R2, and a cron trigger. The public template lives in anysphere/cloudflare-workers, and that matters because this isn’t a partnership announcement without artifacts or a roadmap promise.
The documented deployment creates:
- A Cloudflare Worker as controller.
- A Durable Objects namespace.
- A Cloudflare Containers application.
- An R2 binding for optional repository snapshots.
- A cron trigger that checks for pending Cursor sessions.
Each assigned Cursor session runs in its own isolated Cloudflare Container. Cursor remains responsible for the Cloud Agent session and orchestration. The container opens an outbound connection to Cursor and executes the tool calls Cursor sends over that connection.
That outbound-only model matters. The worker doesn’t need an inbound port or public IP for Cursor to reach the customer’s environment.
How does Cursor Cloud Agents work on Cloudflare?
The pattern separates orchestration from execution.
A user starts a Cursor Cloud Agent and selects a self-hosted team pool. Cursor registers a pending request for that pool. The Cloudflare Worker acts as controller: on each scheduled run, it lists pending requests for the configured pool, keeps a server-sent events stream open during the controller window, claims sessions, and starts a container for each claimed request.
For agents tied to a repository, the request includes the repository URL. The container restores or clones that repository into $HOME/workspaces/repo-0 and then starts the Cursor worker from that directory.
Cloudflare’s documentation shows this command:
agent worker --worker-dir "$HOME/workspaces/repo-0" --pool "$CURSOR_POOL" start --verbose
For any-repository agents, the session is routed by team pool name. The container starts with an empty working directory and no Git remote. The agent, or a project hook, can clone what it needs during the session.
R2 functions as an optional cache, not as the system’s center. Repository snapshots can speed up repo-bound sessions, but a cache miss falls back to a normal git clone and doesn’t prevent the agent from starting.
This is a practical runtime pattern: Cursor decides what the agent tries to do; Cloudflare gives it a controlled place to do it.
What stays in Cursor and what moves to the customer?
Cursor keeps the agent loop, inference, planning, model access, Cloud Agents dashboard, and user-visible orchestration.
The customer-controlled worker executes the tool calls.
That includes terminal commands, file edits, browser actions, repository operations, hooks, local MCP tools when available, access to build systems, access to package registries, and access to internal services the worker can reach.
This distinction matters because “self-hosted” is a loaded word.
If your policy requires that all parts of the agent, including planning and inference, run within your own perimeter, this pattern doesn’t meet that requirement. Cursor is still in the loop.
If your policy requires that source code checkouts, command execution, build artifacts, tool logs, and internal network access stay within company-controlled infrastructure, then this pattern is relevant.
It’s not a private Cursor cloud.
It’s a hybrid execution architecture.
And yet that line is highly significant.
Why this matters for CTOs and CIOs
Because adopting agents in serious engineering organizations is no longer just a question about code quality.
It’s a question about operating model.
An agent that only suggests autocomplete is one kind of risk. A cloud agent that clones private repositories, installs dependencies, runs tests, touches internal services, edits files, produces artifacts, and comments on PRs is another.
Governance questions surface quickly:
- Where does the repository checkout live?
- Where do build outputs and caches live?
- What internal services can the worker reach?
- What secrets are available to the agent runtime?
- Who controls the worker image?
- Who scales the capacity?
- What happens when a container rollout interrupts an active session?
- Where are worker logs retained?
- What artifacts leave the environment and appear in Cursor dashboards or PRs?
The Cloudflare template doesn’t answer everything for you. Cursor’s own documentation is clear: reference architectures aren’t managed production platforms. The customer owns the worker image, infrastructure, secrets, scaling policy, and production validation.
But the template turns those questions into actionable decisions, not abstract debate.
That’s already progress.
Why Cloudflare fits as a runtime for agents
Cloudflare isn’t the only place you can run Cursor Self-Hosted Machines. Cursor’s documentation mentions personal machines, persistent hosts, containers, dynamic infrastructure, Kubernetes, Cloud Run, and partner templates like AWS Lambda, Cloudflare, Namespace, Modal, Daytona, E2B, Vercel, and Coder.
The Cloudflare route is interesting because the controller is also a Worker.
You don’t need to maintain a traditional long-running service just to check if there are pending sessions. The cron trigger runs every five minutes. During a controller execution, the Worker lists pending requests, keeps Cursor’s event stream open until the next scheduled run, claims sessions, and starts isolated containers via a Durable Object.
The result is a serverless-flavored pool controller for agentic execution.
That doesn’t eliminate complexity. It moves it to places platform teams can reason about: wrangler.jsonc, Workers secrets, Durable Objects, container limits, R2 snapshots, image rollouts, logs, and outbound network policy.
For teams already using Cloudflare as part of their edge, security, or development platform, that control plane feels familiar.
It also connects well with a line yoDEV has been following: Cloudflare isn’t just exposing infrastructure services, it’s also turning pieces like Browser Run into programmable blocks for development workflows. That reading appears in our analysis of Cloudflare Browser Run.
What are the requirements for Cursor Cloud Agents on Cloudflare?
As of publication on September 3, 2026, this isn’t a casual recipe for individual users.
Cloudflare’s tutorial requires:
- A Cursor Enterprise plan with Self-Hosted Machines enabled.
- A Cursor service account API key with agent scope.
- A paid Cloudflare Workers account with access to Containers and R2.
- Node.js 20 or later.
- An active Docker daemon for deployment and local development.
The setup also expects Wrangler, a Cursor team pool, a configured CURSOR_POOL, and Worker secrets like CURSOR_API_KEY. If agents need private repositories, Cloudflare’s documentation shows GIT_USERNAME and GIT_TOKEN as Worker secrets; for GitHub, GIT_USERNAME must be x-access-token.
Concurrency is also explicit. The deployment uses containers[].max_instances, and Cloudflare notes it should be tuned to the maximum concurrent requests the deployment needs to support.
That’s a capacity decision, not a checkbox.
There’s another operational detail: Cloudflare warns that rolling out a new container image stops running containers. If agents are working on long-running tasks, deployments need the same change discipline you’d apply to CI workers or production automation.
What should a security team look at?
The most important security point is almost boring, which is usually a sign it’s real.
Running the worker inside your infrastructure doesn’t make the agent secure by default.
It makes the boundary clearer.
The worker can sit closer to private repositories, package registries, staging APIs, build secrets, test databases, internal dashboards, or legacy systems. That’s exactly why this architecture is useful. It’s also why the permissions model matters.
A serious evaluation should decide:
- What repositories the worker can clone.
- What tokens it receives.
- What package registries it can access.
- What internal hosts it can reach.
- What hooks run before or during agent work.
- What artifacts can be uploaded back to Cursor.
- What logs stay on Cloudflare.
- What pools correspond to what risk levels, teams, repositories, or environments.
Cursor’s Team Pools help here because they work as routing targets. A pool can represent a team, a group of repositories, a class of hardware, a staging environment, or a risk level. Cursor’s documentation describes labels for routing work, and admins can allow users to opt into self-hosted runs or require Cloud Agent runs to go to self-hosted workers.
That’s where this stops being deployment plumbing and becomes governance architecture.
What should a company test before adopting it?
A useful test shouldn’t start with a toy app.
It should start with a small, real workflow inside a bounded environment.
For example:
- A private repository with low blast radius.
- A dedicated Cursor team pool.
- A Cloudflare deployment with conservative
max_instances. - A service-account key scoped to authenticate pool workers.
- Minimal Git credentials for the test repository.
- A container image with only the tools needed for the workflow.
- A build or test path that touches an internal dependency.
- Logs reviewed by platform and security.
- A planned image rollout after active sessions end.
The success condition isn’t “the agent made a change”.
The success condition is that the team understands what happens when something fails: capacity exhaustion, wrong Git credentials, missing secrets, cold clones, R2 cache misses, broken tool installs, interrupted rollouts, and failed outbound connectivity.
Agent infrastructure is infrastructure. It deserves failure testing.
What’s the biggest signal?
The biggest signal is that code agents are becoming runtime architecture.
For individual developers, the question usually feels like “which IDE has the best agent”. If you need that more basic frame, yoDEV already has an introduction to what Cursor is and why it matters, plus a practical comparison of Cursor vs VS Code.
For enterprise teams, the question is shifting: where does agent work run and under what controls.
Cloudflare and Cursor show one plausible answer: keep the agent’s commercial experience, but move the execution surface to customer-controlled infrastructure.
It’s not local-first independence. It’s not an open source Cursor replacement. It’s not a universal compliance solution.
It’s a pragmatic middle layer.
And enterprise software adoption usually happens precisely in that kind of middle layer: not pure cloud, not pure self-hosted, but a boundary that lets platform, security, and engineering say yes without pretending the risk disappeared.
Why does this matter now?
The next phase of code agents won’t be decided by model quality alone.
It will be decided by execution boundaries.
Teams adopting agents at scale will need answers about source code location, command execution, network scope, secrets, logs, artifacts, worker images, and audit trails. The Cloudflare template for Cursor is one of the clearest public examples of that architecture becoming real.
The question is no longer just whether an agent can write useful code.
The question is what part of the agent you’re willing to run where.