Self-hosted Cursor agents: what moves and what stays with Cursor

Last checked: 21 Oct 2026. The facts here come from Cursor's Self-Hosted Machines, Team Pools, security and network, private connectivity and cloud agent setup documentation, its help centre, its 2 Sep 2026 blog post, its data residency page and its published terms.

Self-hosting Cursor's cloud agents moves where the agent's tools run (file edits, terminal commands and local MCP servers) onto machines you operate. Cursor still runs the agent loop, the model inference and the planning, and file contents, terminal output and diffs still travel to Cursor during a run. Cursor's own documentation makes its managed cloud agents the default and says that if private network access is your main requirement, you should try the managed route first.

This post is for a CTO, head of engineering or platform lead whose security team has asked for self-hosted agents as a condition of using Cursor. It covers what that request buys, what you take on, when it is worth it, and which managed controls may answer the concern behind it.

What moves to your machines and what stays with Cursor

Cursor calls the feature Self-Hosted Machines. Its documentation says it "moves Cloud Agent tool execution to a machine you manage", and that "Cursor runs the agent loop, inference, and planning. Your worker performs file edits and terminal commands" (Cursor, Self-Hosted Machines). The agent loop is the control logic that decides each step. Cursor's blog calls the same component the agent harness (Cursor blog, 2 Sep 2026).

There are two configurations. My Machines runs the work on one person's machine. Team Pools is a shared fleet of workers, which Cursor describes as "an infrastructure-ownership choice" that does "not move the agent loop out of Cursor's cloud" (Cursor, Team Pools). The help centre answers the obvious follow-up: "No. Cursor is not an on-prem product" (Cursor help centre).

Sources: Cursor, choose where Cloud Agents run, Self-Hosted Machines and Cloud Agents, checked 21 Oct 2026.

The connection runs one way. The worker opens a long-lived outbound HTTPS connection, and "Cursor never connects into your network". No inbound ports, public IP addresses or VPN tunnels are needed (Cursor, Self-Hosted Machines). That is easy to approve at the firewall, and it also means a worker cannot do anything without a live link to Cursor.

Do not confuse this with the Cursor SDK's local mode, which runs the agent loop in your own Node process with files read from disk. Cursor's SDK reference says "local" describes where the agent loop and filesystem access run, "not where the model runs", and that all inference goes through Cursor's hosted models (Cursor SDK reference). Self-hosted workers are reached from the SDK and API through an environment option that routes a cloud agent run to a pool or machine you operate.

What still leaves your network during a self-hosted run

Cursor's documentation is specific: "The full checkout, build cache, and machine-local credentials stay on your machine. During a run, the worker sends Cursor the content the agent needs, such as file contents, terminal output, diffs, screenshots, local MCP results, and routing metadata" (Cursor, Self-Hosted Machines). Its 2 Sep 2026 blog adds: "Tool outputs flow back to Cursor for inference and may contain code, and agent transcripts may be processed and stored by Cursor" (Cursor blog). Cursor's launch material in March 2026 described the boundary more broadly. Plan around the current documentation.

• Artifacts. The worker uploads screenshots, videos and log references to Cursor-managed storage. Blocking the artifact hosts stops the uploads without stopping the agent, but the artifacts then do not appear in pull requests or the dashboard. Cursor advises keeping secrets out of tool output and artifacts (Cursor, Self-Hosted Machines).
• Privacy Mode. It applies to self-hosted workers. When it is on, code sent from the worker is not used for training by Cursor or model providers (Cursor, Self-Hosted Machines).
• Retention by providers. Cursor says it holds zero data retention agreements with model providers, but that providers, including Cursor, may run abuse classifiers and flagged prompts may be stored for investigation (Cursor, Data Use). Keep that qualification in your risk register.
• Live workspace. This optional feature is off by default. When it is on, anyone who can open one of the worker's agents gets a terminal and file access as the worker's operating system user (Cursor, Self-Hosted Machines).

What your team takes on

Cursor sets out the ownership of a Team Pool in one sentence: "Your team runs the fleet, keeps enough workers available, patches and flashes images, resets VMs between runs, manages capacity, rotates credentials, monitors health, and handles host failures" (Cursor, choose where Cloud Agents run). Partner guides and templates are reference architectures only, and "You own the worker image, infrastructure, secrets, scaling policy, and production validation" (Cursor, Self-Hosted Machines).

Less obvious is what does not carry over from the managed product. A self-hosted run uses only the environment's repositories, plus team and user secrets for pool workers that opt in to Secret sync. "Every other environment setting applies only to Cursor-hosted Cloud Agents, so you set those up on the machine" (Cursor, Self-Hosted Machines). In practice:

• Environment preparation. Managed Builds prepare environments in the background so agents start with dependencies ready (Cursor, Cloud Agents). Self-hosted workers need a prepared image or warm workers instead.
• Secrets. Environment-scoped secrets and build secrets never reach a worker. My Machines workers use the machine's own credentials. Pool workers get team and user secrets only when started with a flag and a team admin enables Secret sync, and Cursor stores those synced secrets encrypted at rest (Cursor help centre).
• Egress control. Cursor's admin-locked network policy does not reach self-hosted machines. Those runs "use the machine's own network, firewall, and proxy" (Cursor, security and network).

The egress point matters more than it looks. Cursor says its agents have internet access by default and that auto-running commands carries a data exfiltration risk through prompt injection (Cursor, security and network). Our reading of the documentation is that self-hosting does not remove that risk. The agent still runs commands automatically, now on your worker, and containing it becomes your firewall's job. A permissive corporate firewall can leave you with weaker egress control than the managed allowlist.

Some behaviour also changes. Self-hosted workers run command-based hooks only, so prompt-based hooks do not run (Cursor, Team Pools). MCP servers using the stdio transport run on the worker and can reach your private network, while HTTP-based MCP servers are connected from Cursor's backend, and Cursor's help centre says some MCP gaps remain on self-hosted workers. The feature is young: Cursor tells customers to treat its worker controller and autoscaling setups "as early deployments", and its CLI changelog carries regular fixes for self-hosted workers. Budget time for keeping workers updated.

What self-hosting costs

Cursor publishes no self-hosting price. It publishes the mechanism: "Every runtime option uses the selected model and follows its pricing. Cursor-managed Cloud Agents include the execution infrastructure. With Self-Hosted Machines, you also pay for and operate your machines, containers, or cluster" (Cursor, Self-Hosted Machines). The documentation describes no separate self-hosting fee. Check your order form on that point.

The cost question therefore becomes an infrastructure and staffing question. A pool worker serves one agent at a time and requests wait until one is free, and there is no fixed worker specification: Cursor says to size workers as you would a CI runner for the same repository. Keeping every machine up between turns "gets expensive", while releasing machines means a follow-up may land on a fresh machine that spends its first minutes rebuilding the workspace unless you set up hibernation (Cursor, Team Pools). Someone also has to own the fleet, in the way someone owns your CI runners today.

Team Pools need a Cursor Enterprise plan and a service account API key, because personal logins cannot start pool workers. Service accounts are included with Enterprise at no extra cost and do not use a seat (Cursor, service accounts).

When self-hosting is worth it

Managed cloud agents are "the recommended path for most teams", and Cursor states that they "cover the requirements of over 80% of our customers" (Cursor, choose where Cloud Agents run). That is Cursor's figure, with no stated basis. Its documentation gives three reasons to self-host when the managed cloud cannot meet your constraints (Cursor, Self-Hosted Machines):

1. Strict network requirements, where code or services cannot be reached from outside your network.
2. Custom hardware, such as GPU machines or Macs for iOS development.
3. Custom images, such as a different operating system or an existing build pipeline, that are difficult to save as a Cloud Agent build.

For Team Pools, Cursor adds dedicated hardware profiles "such as GPU workers or high-memory build machines" (Cursor, choose where Cloud Agents run). This is the real case for heavy build systems. If your build needs more memory than a default agent VM, or depends on a pipeline that cannot be reproduced as a Cloud Agent build, self-hosting solves a genuine problem. Check one thing first: managed agents run on a default profile with limited memory and CPU, and Enterprise customers can ask Cursor support to raise those limits (Cursor, cloud agent setup).

The choice does not have to be all or nothing. Cursor's published Navan story describes GitHub work running on Cursor-managed infrastructure while internal MCP servers for Snowflake and Slack run on Navan's own self-hosted machines (Cursor blog, Navan). That is a vendor-authored account.

Managed controls that answer the usual security concern

The concern behind a self-hosting request is usually about agents reaching private systems, credentials leaking, or code going somewhere it should not. Cursor's position is that "You don't need to own the compute to keep agents inside your security perimeter" (Cursor, Self-Hosted Machines).

Sources: Cursor, security and network, private connectivity, setup and identity, checked 21 Oct 2026.

The private connectivity limits mark a genuine self-hosting case: if your Git hosting can only be reached over SSH or uses self-signed certificates, the managed route will not reach it today. Cursor also states that each managed agent runs in its own VM boundary, in a separate AWS account from the rest of its production infrastructure, and that its employees do not have access to the code in those VMs (Cursor, Cloud Agent security). Treat those as Cursor's claims to test. Our post on Cursor cloud agent security covers these controls in detail, and the security review your AI agent should pass gives the wider checklist.

The UK position, and what to get in writing

Self-hosting does not give you data residency, because inference stays in Cursor's cloud. Cursor's US-only residency option is available to Enterprise teams and covers Cloud Agents, and "EU + UK inference-only coverage is available on request" (Cursor, privacy and data governance). That page says nothing about self-hosted workers. Cursor's subprocessor list says its infrastructure is primarily hosted in a US AWS region (Cursor Trust Center), its DPA refers to UK GDPR and the Data Protection Act 2018, and its privacy policy says personal data is processed in various jurisdictions including the United States. Check the transfer terms with your own counsel, and see our post on UK data residency and GDPR across AI vendors.

For managed agents, conversation history is kept indefinitely by default, environment snapshots for up to 30 days of inactivity, and Enterprise admins can choose a 90-day window (Cursor, security and network). The documentation does not say whether those rules apply to conversation state from a self-hosted run.

The contract position is also moving. Cursor's master services agreement was last updated on 12 Oct 2026 (Cursor MSA), its pricing page now links to SpaceX Super Intelligence (SpaceXSI) subscription terms (Cursor pricing), and SpaceXSI has published addenda dated 7 Oct 2026 that take effect when an existing team customer unifies its Grok and Cursor plans (SpaceXSI Cursor addendum). Before a pilot, ask Cursor in writing:

• Which terms govern your account today, and when that will change.
• Whether retention settings, residency and Privacy Mode commitments cover transcripts and tool output from self-hosted runs.
• Which plan My Machines needs, since the documentation does not say.
• Whether your workspace can have higher managed VM limits before you build a fleet to get bigger machines.

Our guide to Cursor for regulated businesses maps these questions to controls, and our guide to cloud coding agents and data security sets the same question against other tools.

Common questions

Does self-hosting keep our code inside our own network?

Not entirely. The full checkout, build cache and machine-local credentials stay on your machine. During a run, the worker sends Cursor file contents, terminal output, diffs, screenshots and local MCP results, and artifacts upload to Cursor-managed storage.

Which Cursor plan do we need for self-hosted agents, and what does it cost?

Team Pools need an Enterprise plan and a service account API key. The documentation does not state a plan requirement for My Machines. Model usage follows the same pricing in every runtime, and you add the cost of your own machines and the people who run them. Cursor publishes no self-hosting price.

When is self-hosting worth it compared with Cursor-managed agents?

When strict network requirements, custom hardware such as GPU machines or Macs, or images and build pipelines that cannot be saved as a Cloud Agent build rule out the managed route. Cursor says its managed agents cover the requirements of most of its customers.

Can Cursor's cloud agents reach our private systems without self-hosting?

Often, yes. Managed agents can use network allowlists, a private-network client such as Tailscale or Cloudflare Tunnel inside the environment, and, on Enterprise, private connectivity for private source control and package registries. Private connectivity does not support SSH, self-signed certificates or custom ports.

Does self-hosting help with UK data residency or GDPR?

Not by itself. Inference stays in Cursor's cloud, Cursor describes its residency options for managed Cloud Agents, UK coverage is inference-only and on request, and the documentation says nothing about self-hosted runs. Ask Cursor in writing and take advice on international transfers.

If your security team has asked for self-hosted agents, start by writing down the concern behind the request and checking it against the managed controls above. We use Cursor in our own engineering and can work through that assessment with you: book our diagnostics, or see our SpaceXSI implementation services and Request a Quote. Our guide to SpaceX Super Intelligence for UK business covers Grok, Cursor and Grok Bot together.

John Kelleher holds the SpaceX Super Intelligence Partner Network Accreditation: Forward Deployed Engineer.