What Cursor's Self-Hosted Machines Actually Change for SaaS Teams

Cursor shipped Self-Hosted Machines on 2 September 2026. The headline writes itself: run Cloud Agents on your own iron. The useful sentence is narrower.

Cursor's announcement and help docs say the same thing. Tool execution can move to a machine you manage. The agent loop, inference, and planning stay in Cursor's cloud. This is not Cursor becoming an on-prem product.

That distinction is the whole article. If you brief your board that 'code never leaves our network,' you will be wrong. File edits and terminal commands can stay on your worker. Tool outputs still go back to Cursor for the next inference step, and Cursor says those outputs may contain code. Transcripts may be processed and stored. Read the primary pages before you send a Slack announcement.

What actually shipped

Cursor-hosted Cloud Agents stay the default. Each hosted session still gets a dedicated VM, dependency install, isolation, secret redaction, egress controls, and signed commits. Cursor says that meets most teams.

Self-Hosted Machines is the other path. You install the Cursor CLI and run agent worker start. The worker opens a long-lived outbound HTTPS connection. Cursor never needs an inbound hole in your firewall. When a session starts, Cursor plans, then sends tool calls down that connection. The worker edits files, runs commands, can drive a browser if you installed the computer-use dependencies, and can run local stdio MCP servers.

Two shapes:

• My Machines: one laptop, devbox, or VM tied to a person. Good when that machine already has the repo state you care about.
• Pools: a named queue of workers for a team. A controller watches the queue and can spawn machines with your script. Idle workers can time out, reset, or hibernate from a snapshot so follow-ups do not rebuild the workspace from scratch.

Pools are not glued to one repository. A request names a pool. Any free worker can claim it. Cursor also listed sandbox partners instead of forcing you to build a jail: AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, and Vercel. If you already pay Vercel, that is the path I would try before buying a fleet of idle VMs.

Who should care this week

Care if one of these is true:

• Agents need direct access to source control or internal services that you will not expose to a Cursor-hosted VM.
• The work needs a Mac for iOS, a GPU, Kubernetes, or some other shape that is painful to package as a Cloud Agent build.
• Security already said no to hosted execution, and this is the conversation that unblocks the team.

Ignore it, for now, if you are a small SaaS team whose repo already lives on GitHub and whose secrets already live in a hosted CI system. You are not getting a new capability by operating a worker. You are getting a new on-call surface. Cursor still recommends hosted agents for most teams, including teams that need private network access through allowlists and similar tools.

What this changes commercially

For founders, the question is not 'are we serious about AI' if you skip this launch. The question is whether Cloud Agents can touch the systems that make them useful.

A lot of agencies will now sell a three-week 'Cursor on-prem enablement' with workshops and a RACI. Most of that is process. The real work is: which repos, which secrets, which spawn script, who gets paged when a worker dies, and whether you even needed to leave hosted. Outcome over theater.

Cursor said cloud agents already create more than 60% of the pull requests they merge internally. Treat that as their number, not yours. Your number is how many agent PRs you would merge if the agent could reach the package registry and the staging database without a human copying files around.

If agent spend is already the painful part, where the VM lives will not save you. Model choice, caching, and what you let the agent retry still dominate. I wrote about those levers in your AI agent bill becoming a second rent payment.

What I would do

If I were advising a SaaS team this week:

1. Keep hosted Cloud Agents on unless security has a written objection that hosted isolation does not answer.
2. If the objection is 'our monorepo and internal API cannot leave the VPC,' pilot one pool on a sandbox you already operate, preferably Vercel or Lambda, not a pet VM under someone's desk.
3. Write down what still goes back to Cursor: prompts, tool results, transcripts. Get legal to read Cursor's words, not a vendor slide.
4. Do not let agents become an unsupervised employee. Human review on anything that touches production data, payments, or permissions. Guardrails are still the job.

Shipping agents that survive contact with real work is still mostly retries, observability, and ownership. That layer did not get easier because the worker moved. See agentic workflows that actually ship.

If your security team blocked Cloud Agents, or you want them on internal services without turning the company into an infrastructure project, send me the constraint. I will tell you whether hosted, My Machines, or a pool is the grown-up answer.