Cursor Self-Hosted Machines put tool execution on your workers

Cursor published Self-Hosted Machines on 2026-09-02: cloud agents can execute on dynamically scheduled pools of machines inside your network. You manage the infrastructure; agents are still started and managed from Cursor. Cursor-hosted VMs remain the default. Self-Hosted Machines move tool execution onto a worker you run, while inference and planning stay in the Cursor cloud.

That changes a concrete builder decision: where do agent tool calls run when the product repo, internal services, GPUs, Macs, or build pipelines cannot live inside Cursor's hosted VM? It does not replace owning the product repository—screens, schema, auth, billing, prompts, and deploy still need a home agents can edit.

What Cursor shipped

From the primary post:

• Cloud agents can run on pools of machines you manage inside your network.
• Cursor-hosted environments stay the default: dedicated VMs in Cursor cloud with dependencies, network controls, secret redaction, egress controls, and signed commits.
• Teams use Self-Hosted Machines when tool execution must happen inside their network (source control, internal services, repos), when agents need custom hardware (GPUs, Macs for iOS), or when the OS/build pipeline is hard to package as a Cloud Agent build.
• Only the execution environment moves. The agent loop, inference, and planning remain in the Cursor cloud. Tool outputs flow back for inference and may contain code; transcripts may be processed and stored by Cursor.
• Agents remain reachable from the desktop app, cursor.com, mobile, Slack, GitHub, and Linear.

Workers bridge your machine to the agent loop. Install the Cursor CLI and run:

agent worker start

That opens a long-lived outbound HTTPS connection to the Cursor cloud. Cursor does not initiate inbound connections into your network. When a session starts, the harness plans and sends tool calls to the worker; the worker returns results for the next inference round. The machine holds the working copy, edits files, and runs commands.

Workers configure two ways:

1. My Machines — a single laptop or VM for personal workflows.
2. Pools — a named queue of workers for a team. Capacity rises as requests arrive and falls when workers disconnect.

Pools can scale with a controller that watches the queue and uses a team-supplied spawn script. Idle timeouts can reset workers back into the pool; hibernation can snapshot and stop an idle machine, then restore it if a follow-up arrives inside the reconnect window. Pools are not tied to one repository: any available worker can claim a request that names the pool.

Cursor also lists sandbox partners for worker orchestration (AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, Vercel) and notes Linux workers can do computer use (browser click/screenshot) alongside Macs when Chrome/Chromium dependencies are installed.

Those are the verifiable product claims. The rest of this post is what builders should still own after they connect a worker.

What moves, and what does not

Self-Hosted Machines answer "where does the tool call execute?" They do not answer "where does the product live?"

Moved to your side. File edits, commands, local build tools, access to internal APIs, custom hardware, and whatever your worker's network can reach.

Stays in Cursor cloud. Inference, planning, the agent harness, and the surfaces that start sessions.

Still your product problem. Domain schema, auth and billing seams, screen inventory, agent prompts and architecture notes in the repo, and deploy scripts. A worker that can npm test against an empty or tribal-knowledge codebase will still thrash.

If your pain was "the agent cannot reach our private packages or Mac builders," Self-Hosted Machines is on-topic. If your pain was "every agent session rediscovers how checkout and entitlements work," fix the owned product spine first—then decide whether execution should be Cursor-hosted or self-hosted.

Related ownership framing for putting kit spine in the repo before handing a coordinator the wheel: /blog/cursor-projects-owned-repo.

When self-hosted execution is the right next step

Use the primary post's own triggers, then add product-repo honesty.

Prefer Self-Hosted Machines when

1. Tool execution must see internal source control, services, or packages Cursor-hosted VMs cannot reach cleanly.
2. You need GPUs, Macs for iOS/macOS work, Kubernetes, or other sandboxes already in your fleet.
3. Your OS or build pipeline is awkward to encode as a Cloud Agent build.
4. You can run agent worker start (or a pool spawn path) and accept outbound HTTPS from workers to Cursor.
5. You already have—or are actively building—an owned repo with schema, auth, prompts, and deploy that agents can edit.

Stay on Cursor-hosted VMs when

1. Default isolation, secret redaction, and egress controls already meet the requirement.
2. The repo and dependencies fit a normal Cloud Agent build.
3. You do not want to operate workers, pools, idle timeouts, and hibernation yet.

Do not use self-hosting as a substitute for product ownership. Putting a worker next to a messy monorepo without documented seams just moves the same rediscovery onto hardware you pay for.

Operating checklist after agent worker start

1. Name the pool or machine purpose. Personal My Machines vs team Pools—write which repos they may claim.
2. Put product context in the repo. Architecture notes, commands, and tested prompts so workers execute against known conventions.
3. Map secrets carefully. Tool outputs return to Cursor for inference and may include code. Treat worker environment variables and redaction policy as part of the design, not an afterthought.
4. Decide idle vs hibernate. Leaving machines hot is expensive; cold starts can cost minutes. Use the reconnect window intentionally.
5. Prove a real ship path. Auth, data, payments, and deploy should still run from owned source—whether the agent executed on Cursor-hosted or self-hosted compute.

For a concrete post-purchase path once a vertical kit is the owned spine, see /blog/fitness-kit-after-purchase.

Self-Hosted Machines are a real change for teams that needed agent execution beside internal systems and custom hardware. Keep the boundary clear: Cursor still runs the agent loop in its cloud; you run the worker; the product still needs an owned repository agents can trust.

A concrete session shape

A useful mental model for the first production trial:

1. Start from a repo that already has a documented install and test command in-tree.
2. Register either a My Machines worker for a single engineer or a small Pool with a known spawn script.
3. Run one bounded task that needs an internal dependency Cursor-hosted VMs struggle with—private package install, Mac simulator step, or a service only reachable on your network.
4. Capture whether the worker returned usable tool output without leaking secrets in transcripts you are not willing to store.
5. Only then widen pool capacity. Scaling workers before the product repo is agent-readable just multiplies thrash.

That sequence keeps Self-Hosted Machines honest: it is an execution placement feature, not a substitute for product documentation and owned seams.

Sources

• https://cursor.com/blog/self-hosted-machines — Self-Hosted Machines announcement (2026-09-02); Cursor-hosted default; worker via agent worker start; My Machines vs Pools; outbound HTTPS only; partners; Linux/Mac computer use
• https://otf-kit.dev — owned full-stack web and mobile kits
• https://github.com/otf-kit/sdk — OTF SDK outbound default