Cursor's self-hosted runners feel on-prem: here's where the agent loop still runs

Cursor shipped a quiet expansion of Cloud Agents last week: self-hosted machines, team pools, and...

Cursor shipped a quiet expansion of Cloud Agents last week: self-hosted machines, team pools, and persistent Projects with a coordinator agent that can run for months. Most of the coverage focused on the coordinator story. The part I kept testing this week is narrower and more useful: where do tool calls actually run now, and what does a rules file even mean when the executor moves onto your machine while the brain stays in a datacenter you don't control.

The setup is a worker model. You install the Cursor CLI on a machine you own and run agent worker start. That process opens one long-lived outbound HTTPS connection to Cursor's cloud, and Cursor sends tool calls down that pipe. Your machine executes terminal commands, file edits, and browser actions locally. No inbound ports, no public IPs, no VPN tunnels. Workers need outbound HTTPS to exactly three hosts: api2.cursor.sh and api2direct.cursor.sh for the agent session, and cloud-agent-artifacts.s3.us-east-1.amazonaws.com for artifact uploads. If you run a proxy, HTTPS_PROXY covers it.

What actually stays on your machine

The docs are specific about the split, and it is worth reading twice. The agent loop, meaning state maintenance, planning, and inference calls, runs in Cursor's cloud. The worker handles the process side: file edits, terminal commands, browser actions, and stdio MCP servers. Your source code, build artifacts, and secrets stay on your hardware.

But read the artifact line again. File chunks the model reads during inference get uploaded, along with screenshots, videos, and log references, so they can render in pull requests and dashboards. That is by design and it is how the product shows you what happened. The boundary is not air-tight in the way a compliance officer might hope. Cursor says raw code and secrets are not stored in Cursor-managed infrastructure, but content that crosses the loop boundary by necessity (the chunks inference needs) does leave your network. The docs also note you can block cloud-agent-artifacts.s3.us-east-1.amazonaws.com outbound on the worker; the agent keeps working, you just lose artifacts in PRs and the dashboard. That is a real lever for strict environments, and I have not seen it called out in the launch coverage.

Not on-prem, and Cursor says so directly

The help page asks the question itself: "Is Cursor on-prem now?" The answer is one word: no. The worker connects outbound, Cursor sends agent requests down that connection, and your network stays unreachable from the internet. That outbound-only shape is the whole security story, and it is a good one for home-lab and mid-size setups: you keep your firewall untouched, your keys stay local, and tool execution happens next to your data.

It is still a split-trust model. Planning and model access sit in Cursor's cloud. If your threat model says no code chunk may ever reach a third party, self-hosted runners do not get you there; managed Cloud Agents with private connectivity (AWS PrivateLink, Cloudflare Tunnel) address a different problem, reaching private source control from Cursor's cloud. The docs recommend most teams stay managed and use network controls plus Tailscale before operating a worker fleet. That recommendation is honest, and it matches what I saw setting a worker up: the operational lift is real once you own patching, resets, capacity, and monitoring.

Where your rules file lands in this split

This is the part that connects to how I already run agents. In a local-first tool, .cursor/rules and hooks run in the same process as the agent, so a rule is a statement about what the agent may do on this machine. With a self-hosted worker, your rules and hooks travel with the worker: .cursor/hooks.json sits in the worker directory, and sessionStart/sessionEnd hooks fire when a session claims or releases the worker. stdio MCP servers run on the worker and can reach private networks. HTTP and SSE MCP servers still run from Cursor's backend, with some gaps the changelog tracks.

So your guardrails execute where the tools execute, which is the right side of the split. But the thing deciding what to attempt, the model, runs on the other side. The rules file constrains execution, not intent. If you are used to thinking of rules files as policy, this is the shift: policy enforcement is local, policy drafting context is remote. A worker that stops trusting its config is still reachable only through the outbound session, which limits blast radius nicely.

Two earlier pieces cover the neighbors of this problem: Claude Code's new mods run in-process and can intercept tool calls before your hooks see them, which puts guard and executor in the same process with the opposite trust shape (Claude Code 2.1.287 mods), and Copilot's computer-use preview moves execution onto your desktop with a permission model your rules file can partially see (Copilot computer use guardrails).

The pool routing is the interesting design bit

For teams, self-hosted machines grow into pools. A pool is a named queue: requests wait until a worker claims them, one agent per worker at a time. Pools are not repo-tied; you label workers (say gpu, ios) and requests match on labels, with repo=owner/name reserved and auto-derived. Capacity can scale with demand via a controller, and there is a Kubernetes path with a Helm chart and an operator managing WorkerDeployment resources, warm capacity, rolling updates, and token rotation. Limits: up to 200 workers per user, 1000 per team, Enterprise plan required for pools, service-account API keys only (personal keys are rejected for pool workers).

The trigger surface is where routing decisions leak into daily workflow. From Slack, @Cursor self_hosted=true or sh=1; from GitHub, @cursoragent pool=<name> on an issue or PR; Linear takes pool= in the issue body or labels. Admins get two switches: Allow (members opt in per request) and Require (every run routes to your workers). GitHub permission-scoping is thought through: only OWNER and COLLABORATOR can route runs to self-hosted workers, so a random commenter on your public repo cannot push work onto your infra. That detail tells you Cursor thought about the abuse case, and it is the kind of small print worth knowing before you enable anything org-wide.

Where I would actually use this

Three concrete fits, from the docs' own decision table plus my bias toward machines I already operate. One engineer, one box: My Machines, your devbox with its existing checkout and credentials, no fleet to run. Org fleet or GPUs: Team Pools with labeled workers. Partner VM or sandbox: integrations, with Cloudflare, Modal, Namespace, E2B, Daytona, and others listed as supported worker hosts.

What self-hosting does not fix: the agent loop still depends on Cursor's cloud availability and pricing, Privacy Mode covers training use but inference still processes your file chunks, and you inherit fleet operations (patching, image resets, credential rotation) that managed agents previously absorbed. The honest framing is that Cursor moved execution to your hardware and kept the brain. For a lot of compliance stories that is exactly the trade you want. For full sovereignty it is not, and no amount of worker configuration changes that.

If you maintain version-pinned agent configs across tools, this split is one more surface to model: same tool family, two trust domains, one rules file that now has to reason about which side of the pipe each line executes on. That is the piece I would audit before pointing a pool at anything with production secrets.

If you want a ready-made starting point for pinned configs across Claude Code, Cursor, and Codex, I keep AgentConfig Studio ($29) updated for exactly these transitions, and the free Next.js sample shows the same structure for one stack.