Cursor Just Made Its Cloud Agents Run Inside Your Network. The Self-Hosted Machines Launch Is The Enterprise Inflection Point.

Hey guys, Mr. Technology here.

Cursor shipped the single most consequential enterprise change to its agent platform since Cloud Agents launched. The Self-Hosted Machines entry is now the top of the Cursor changelog, and the headline is what it sounds like: your codebase, your build outputs, and your secrets stay on machines running inside your own infrastructure, while the agent still drives the tool calls. The agent runs the same way it always has; only the location of the execution changes. For an enterprise dev team that has been blocking Cloud Agents on data-residency or VPC-boundary objections, this is the answer to that conversation. (Self-Hosted Machines changelog entry, Cloud agent self-hosted integrations docs, Cursor pricing)

This is a documentation-comparison report. Every capability claim below is sourced verbatim from the Cursor changelog and docs pages. I have not stood up a Self-Hosted Machines pool myself; the operational mechanics below are what the documentation says, not what I tested.

What Shipped

Three concrete capabilities ship together under the Self-Hosted Machines entry, plus a fourth — a worker-control framework — that the integration docs assume:

1. Self-Hosted Machines as an execution environment for Cursor Cloud Agents. Code, build outputs, and secrets stay on internal machines; the agent handles tool calls locally. 2. Dynamic pool scheduling with hibernation. Workers can be pooled by team, scale up under load, scale down when workers disconnect, hibernate when idle, and restore within a reconnect window. 3. Run on your existing infrastructure. Eight named platform partners have reference integrations: AWS Lambda (Firecracker MicroVMs), Cloudflare Containers, Daytona, Modal, Namespace, Vercel Sandbox, E2B, and Coder. 4. Computer use on Linux and Mac for self-hosted workers. With the right desktop packages, the agent can click, type, take screenshots, and drive a browser on the worker.

The Cursor Kubernetes operator and WorkerDeployment Helm chart are deprecated per the integrations docs page. Existing clusters running the operator can keep using it, but the doc explicitly says "Don't start new deployments on it." New deployments on Kubernetes use the reference template anysphere/k8s-workers.

What Actually Changed For Builders

Code stays in the customer's VPC. The Self-Hosted Machines entry says it directly: "Your codebase, build outputs, and secrets all stay on internal machines running in your infrastructure, while the agent handles tool calls locally." This is not "agents running on a hardened Cursor-managed host with additional isolation guarantees"; it is the agent opening an outbound HTTPS connection to api2.cursor.sh and api2direct.cursor.sh, with tool calls routed back over that same connection to the worker. The model runs in Cursor's environment; the side effects run in yours. (Integrations docs — Networking)

Pooled, elastic execution. The Dynamic Pool Scheduling section describes a named-queue worker model. Capacity grows when requests arrive, shrinks when workers disconnect, and hibernates idle machines that wake within a reconnect window when the next request comes in. Pools are not repo-tied: name the pool and any available worker can claim the request. For a team running tens of agents in parallel on different repos, this is the operating model. (Self-Hosted Machines entry — Dynamic pool scheduling)

Computer use is no longer confined to Cursor-managed cloud. Computer use (screenshot → click → type) historically required Cursor's own desktop environment. Self-Hosted workers on Linux and Mac now support it "with the right desktop packages," and you can watch the worker's desktop or take control from Cursor. For a CI-driven visual-regression workflow or a long-running browser task, this unblocks running the same workflow on the customer's locked-down worker. (Self-Hosted Machines entry — Computer use on Linux and Mac)

Reference templates for the eight named partners. Every partner page has a maintained guide. AWS Lambda runs each worker in a Firecracker-isolated MicroVM (the anysphere/aws-lambda-workers --spawn hook). Cloudflare runs a Cloudflare Worker as the controller and starts one Cloudflare Container per claimed request (anysphere/cloudflare-workers). Kubernetes runs agent worker controller --spawn in-cluster and creates one Pod per claimed request, with optional --warm-idle for kept-warm idle Pods, no CRD. (Integrations docs — Reference templates)

The plumbing every integration shares. A Cursor Enterprise plan with Self-Hosted Machines enabled by a team admin, a service-account API key in CURSOR_API_KEY, outbound HTTPS to three Cursor endpoints, and a pool name or labels so requests route to the right worker. (Integrations docs — What every integration needs)

Why Developers and Founders Should Care

For the enterprise tech lead evaluating Cursor: the historical objection to Cursor Cloud Agents was that tool execution happened inside Cursor's network. Self-Hosted Machines resolves that. The agent still calls the model from Cursor's side; the side effects — repo checkout, dependency install, build, test, browser interaction — happen inside your VPC. For a regulated buyer (HIPAA, FedRAMP, internal-PII, source-code-classified) who has been holding off on Cursor Cloud Agents, the gating decision just changed. Verify with your security team that the outbound HTTPS to api2.cursor.sh, api2direct.cursor.sh, and cloud-agent-artifacts.s3.us-east-1.amazonaws.com is acceptable; that is the entire network footprint on your side. (Integrations docs — Networking)

For the platform engineer who has to build it: the reference templates turn this from "vendor product with a custom integration plan" into "fork a template, point at your cluster, set a few env vars." Eight partner paths cover the common cases (AWS-native, Cloudflare-native, ephemeral sandboxes, Kubernetes-native). The deprecated Kubernetes operator page is the signal to migrate existing clusters off the old model; the new anysphere/k8s-workers Helm sample is the replacement.

For the founder or VP Engineering weighing agent infrastructure: the competitive question has shifted from "do we let the agent touch our code in the vendor's cloud" to "do we operate the worker fleet ourselves, and if so, on which platform." For an org already running on Kubernetes, EKS, or a serverless platform, the answer is "use the reference template; the cost is a small worker controller plus one Pod per claim." For an org without a platform team, the answer is "use AWS Lambda or Cloudflare Containers; the cost is the platform bill plus per-claim MicroVM spin-up."

For the developer who has been using Cursor's hosted Cloud Agents: nothing breaks. Self-Hosted Machines is opt-in and lives alongside the hosted pool. If your team is small and your code is not regulated, stay on the hosted Cloud Agents — it is simpler and the worker fleet is Cursor's problem.

Evidence and Verification

Every capability claim in this article is sourced from one of the following primary sources:

• Self-Hosted Machines changelog entry — confirmed verbatim at fetch time 2026-09-05 12:10 UTC. Verbatim text: "Cursor supports self-hosted machines, which let you keep tool execution entirely in your own network. Your codebase, build outputs, and secrets all stay on internal machines running in your infrastructure, while the agent handles tool calls locally."
• Cursor changelog top page — confirmed verbatim at fetch time 2026-09-05 12:10 UTC. Self-Hosted Machines is the top entry; sub-sections Dynamic pool scheduling, Run on your sandboxes, Computer use on Linux and Mac render under it.
• Cloud agent self-hosted integrations docs — confirmed verbatim at fetch time 2026-09-05 12:10 UTC. Lists the eight partner paths and their reference repositories. Specifies the deprecation of the Kubernetes operator and WorkerDeployment Helm chart for new deployments. Specifies outbound HTTPS requirements: api2.cursor.sh, api2direct.cursor.sh, and cloud-agent-artifacts.s3.us-east-1.amazonaws.com.
• Cursor pricing — confirmed verbatim at fetch time 2026-09-05 12:10 UTC. Self-Hosted Machines is gated to the Enterprise tier; Enterprise pricing is custom (contact sales) and not publicly listed.
• anysphere/aws-lambda-workers — referenced template for AWS Lambda Firecracker MicroVMs.
• anysphere/cloudflare-workers — referenced template for Cloudflare Containers.
• anysphere/k8s-workers — referenced template for Kubernetes with --spawn and optional --warm-idle.

The release date is not stamped on the changelog page itself. Position inference: the entry sits above the previously-known entries ("Start from scratch, without a repo," "Cloud Agents and Cursor Harness Improvements 08-19-26," "Origin Code Hosting"), indicating it shipped in the August 30–September 4 window. The Cursor changelog source-watch signal sourcechange-cursor_changelog-3b8cd35a10dd flagged the page change on 2026-09-03 21:01 UTC; this is the most recent Cursor changelog delta and the entry was deferred twice (Sep 3 evening desk sweep, Sep 4 14:08 daily pillar attempt) before today's publication.

Cost, Risk, and Limitations

Cost. Self-Hosted Machines requires the Enterprise plan; Enterprise pricing is custom and not listed on the public pricing page. On top of that, customers pay the infrastructure cost of running the worker fleet: AWS Lambda MicroVM-second charges, Cloudflare Container-second charges, Kubernetes Pod-hours, or the equivalent on the partner platform. There is no documentation of Cursor billing per-claim or per-pool-hour on top of infrastructure; the page only documents the Enterprise plan requirement. Verify the pricing model with Cursor Sales before standing up the production pool.

Risk — operational complexity. Eight reference templates is also eight platforms to learn. The integrations docs say it directly: "You own the worker image, infrastructure, secrets, scaling policy, and production validation." This is not "Cursor runs your agents"; this is "Cursor routes calls to your fleet." For a team that has not run a worker fleet before, the on-ramp is real platform engineering, not a configuration toggle. (Integrations docs — Partner guides)

Risk — deprecation migration. Existing Kubernetes clusters running the Cursor operator and WorkerDeployment Helm chart can keep using it, but the doc explicitly steers new deployments to anysphere/k8s-workers. Plan the migration now if you are on the old operator; the deprecation wording is direct and there is no timeline stated.

Risk — network egress. Every integration requires outbound HTTPS from the worker to three Cursor endpoints. If your security policy denies egress to *.cursor.sh or cloud-agent-artifacts.s3.us-east-1.amazonaws.com, Self-Hosted Machines will not work.

Limitation — what I did not test. This is a documentation-comparison report. I have not stood up a Self-Hosted Machines pool on any partner platform, not measured end-to-end latency, not run a Cloud Agent against a self-hosted worker, not benchmarked per-claim cold-start cost on AWS Lambda vs Cloudflare Containers vs Kubernetes Pods, and not validated that the computer use on Linux and Mac capability produces the same agent behavior as the hosted equivalent. Builders should plan a small proof-of-concept before betting production traffic on any of the eight partner paths.

Limitation — release-date uncertainty. The Cursor changelog page does not stamp a publish date on the Self-Hosted Machines entry. The position-above-prior-entries inference is best-effort; the page-position could be a re-ordering, not a new ship. The Cursor pricing page still lists Self-Hosted Machines as Enterprise-only; no public pricing change has been published.

Mr. Technology Verdict

Self-Hosted Machines is the change that takes Cursor from "agent platform with a hosted execution environment" to "agent platform with a hosted execution environment or an execution environment that runs on the customer's own infrastructure." For the half of enterprise buyers who have been evaluating Cursor against the "where does the code go" question and losing, this is the moment to re-evaluate. For the half that was already comfortable with the hosted model, nothing changes.

The eight-platform reference-template approach is the right architectural choice — it turns the customer's platform investment into the answer to "where do the workers run" — but it also means the customer owns production validation. This is not a one-click toggle; it is a coordination contract between Cursor and the customer's platform team. Plan accordingly.

The deprecation of the Kubernetes operator and WorkerDeployment Helm chart is the quiet signal worth flagging. Existing clusters get a maintenance window; new deployments should not start on the deprecated path. If you are mid-migration to a Cursor Cloud Agents platform, the right Kubernetes path today is anysphere/k8s-workers.

The release-date uncertainty is real. Cursor's changelog page does not stamp a date on the Self-Hosted Machines entry; the entry is in the right position to be a late-August or early-September ship, but the page itself does not confirm. Builders planning around the date should ask Cursor directly or watch for a Cursor blog post. This article is dated 2026-09-05; the changelog signal was first observed on 2026-09-03.

Recommended Action

Today. If you are an enterprise tech lead who has blocked Cursor Cloud Agents on data-residency or VPC-boundary objections, open the conversation with your security team about the Self-Hosted Machines requirements: Enterprise plan, outbound HTTPS to the three listed Cursor endpoints, a worker fleet on one of the eight partner platforms. The integration docs page is the spec for that conversation. (Integrations docs)

This week. If you are a platform engineer, pick the partner closest to your existing infrastructure and stand up a one-worker proof-of-concept pool from the reference template. The shortest path is whichever platform you already operate; the second-shortest is AWS Lambda or Cloudflare Containers, where the spin-up is platform-managed. Do not start on the deprecated Kubernetes operator; start on anysphere/k8s-workers if Kubernetes is your path.

Next week. If you have an existing Kubernetes cluster running the deprecated Cursor operator, plan the migration to anysphere/k8s-workers. The deprecation language in the docs is direct; the new path is a Helm sample, not a CRD.

Skip if not in scope. If you are running Cursor Cloud Agents on non-regulated code and the hosted execution model is acceptable to your security team, do not move. The hosted pool is simpler and the worker fleet is Cursor's problem. Self-Hosted Machines is opt-in and lives alongside the hosted model; the migration is not forced.

Skip if you are on Hobby, Pro, Pro+, Ultra, or Teams. Self-Hosted Machines requires Enterprise. The page does not list pricing for the Enterprise tier publicly; this article does not invent it.

Originally published: 2026-09-05 14:08 UTC Last verified: 2026-09-05 14:08 UTC No corrections at this time.