Cursor’s September 2, 2026 Self-hosted machines update expands the ways teams can use their own execution infrastructure. It is relevant when a project needs an existing development machine, particular build tools or access to internal services.
The key distinction is the location of execution versus the location of reasoning. We checked the announcement and architecture documentation on September 10.
What runs on your infrastructure?
Cursor’s architecture documentation places file edits, terminal commands, computer-use tools and local MCP servers on a customer-managed worker. Cursor continues to run the agent loop, planning and inference.
That arrangement can help with an environment constraint. It does not, by itself, satisfy a requirement for all processing to remain inside a private network.
A useful review starts with a simple diagram you draw for your own deployment: user interface → orchestration → model endpoint → worker → external tools. Mark the owner and network boundary of every connection. The word “self-hosted” should be attached to a specific component.
What data can leave the worker?
The documentation says the full checkout, build cache and machine-local credentials remain on the machine. It also says the worker sends required context to Cursor, including file contents, terminal output, diffs, screenshots, local MCP results and routing metadata. Artifacts can be uploaded to Cursor-managed storage.
Do not infer “no code leaves” from “the repository is local.” A file read can send relevant code even though the complete checkout stays on disk. Similarly, a local tool can return sensitive content in its output.
For a pilot, use a disposable repository and synthetic values. Review which files tools read, what commands print, and which screenshots or artifacts the workflow produces. This article describes documented behavior; it is not a network-capture report.
My Machines or Team Pools?
| Your operational need | Evaluation starting point |
|---|---|
| One developer’s existing environment | My Machines |
| Shared, centrally maintained worker capacity | Team Pools |
| No connection to cloud orchestration or inference | Evaluate an architecture that meets that requirement explicitly |
Cursor documents personal machines and pooled workers as different operating patterns. Our recommendation is to settle ownership before increasing capacity: who patches the image, rotates credentials, cleans up workspaces and investigates a failed run?
A machine with a successful demo is not yet an operating plan. Include idle time, upgrades and recovery in the decision.
Does self-hosted execution reduce the bill?
Not automatically. Cursor documents continued model billing plus the cost of operating your own workers. Our evaluation recommendation is to compare the complete workflow: model usage, compute, storage, idle capacity, retries and maintenance.
An existing machine may reduce one cost while increasing another. Use measured task outcomes rather than assuming that moving execution changes model prices.
What should you compare next?
If your requirement concerns processing location, begin with the air-gapped AI coding guide and identify every external dependency. For deployment ownership, use the self-hosting checklist.
For permissions within an agent workflow, read the Copilot managed permissions update. These are different questions: where a task runs, where its context goes and which actions it may take. Answering one does not settle the other two.
Frequently asked questions
Is Cursor Self-Hosted Machines a fully on-premises deployment?
No. Tool execution runs on your worker, but Cursor runs planning, the agent loop and inference. The documented architecture requires cloud communication.
Can code leave the network when the repository stays on my worker?
Yes. Cursor documents that required file contents, diffs, terminal output, screenshots and local MCP results can be sent to its service. The location of the full checkout does not determine every data flow.
Does blocking artifact uploads keep all agent data local?
No. Cursor says blocking artifact uploads prevents those uploads while tool calls and results continue. It is not a way to make the agent operate offline.