Cursor Self-Hosted Machines: map the real data boundary before moving agent tools inside
Quick answer
Cursor announced Self-Hosted Machines on September 2, 2026. The feature lets Cloud Agent tool execution run on machines you manage: file edits, terminal commands, local MCP servers, and optional computer use. Cursor still runs the agent loop, inference, planning, and the user-facing Cloud Agent experience.
That distinction is the rollout boundary. The full checkout, build cache, and machine-local credentials can stay on the worker, but the worker sends Cursor the context needed for the run, including selected file contents, terminal output, diffs, screenshots, local MCP results, and routing metadata. Artifacts can also be uploaded to Cursor-managed storage. “Self-hosted” therefore means self-hosted execution, not a fully offline agent.
Who this is for
This guide is for teams considering Cursor Self-Hosted Machines because they need internal services, private package registries, custom hardware, macOS build machines, or an existing controlled image. It is also useful for solo developers evaluating My Machines before granting an agent terminal or desktop authority on a personal workstation.
If managed Cloud Agents plus network allowlists or private connectivity already meet the requirement, keeping Cursor's isolated managed VMs may be operationally simpler. Self-hosting moves patching, capacity, credentials, desktop permissions, and incident response into your boundary.
What changed
The September release introduces two operating shapes:
| Mode | Intended user | Operational boundary |
|---|---|---|
| My Machines | Personal workflows | One connected laptop or VM with personal authentication |
| Team Pools | Enterprise teams | Named worker queues, service-account authentication, admin policy, and capacity management |
Workers require the Cursor CLI and outbound HTTPS. Team Pools require Cursor Enterprise and a service-account API key; personal logins cannot start pool workers. Administrators can allow self-hosting as an option or require Cloud Agent runs to use team workers.
Self-hosted workers can also run computer-use tools. On macOS, that means a signed-in desktop session plus Accessibility and Screen Recording permissions. On Linux, it requires a desktop stack or X11 display. These permissions are material authority, not installation details.
Start with a data-flow matrix
Before connecting a repository, review each data class:
| Data | Stays on worker | Can leave worker | Control to verify |
|---|---|---|---|
| Full checkout | Yes | Selected file contents can be sent as context | Repository allowlist and prompt canary |
| Build cache | Yes | Terminal output may expose paths or values | Log redaction and command policy |
| Local credentials | Stored locally | Values can leak through output, screenshots, or tools | Least privilege and synthetic-secret canary |
| Diffs | Generated locally | Sent to Cursor for review and UI | Repository classification and retention review |
| Local MCP results | Tool runs locally | Results can be sent to the agent loop | Per-server allowlist and response filtering |
| Desktop | Local execution | Live view/screenshots can be streamed or stored | Dedicated account and capture boundary |
| Agent artifacts | Created from local run | Uploaded to Cursor-managed storage | Artifact retention and content policy |
The practical question is not “where did the command run?” It is “which input and output crossed the control plane, and was that allowed?”
Seven-step rollout
1. Decide whether self-hosting is necessary
Write the unmet requirement: private network access, custom hardware, macOS/iOS tooling, or a non-standard image. If private connectivity and managed isolation already solve it, do not inherit a worker fleet without a measurable benefit.
2. Use a dedicated worker identity
Do not start with a daily-use workstation. Create a dedicated OS account or disposable VM, a repository-scoped credential, and a minimal environment. For Team Pools, use the required service-account key and keep it separate from user API keys.
3. Bound filesystem and network access
Limit the workspace root to one synthetic repository. Restrict outbound traffic to documented Cursor endpoints plus the exact package and source-control services required by the canary. Deny unrelated internal services by default.
4. Prove secret non-disclosure
Place a synthetic marker in a credential-like location that the worker does not need. Run a task that inspects nearby files, terminal output, local MCP, and optional screenshots. Confirm the marker is absent from run context, logs, diffs, artifacts, and the Cloud Agent UI.
5. Test local MCP separately
Inventory every MCP server, its tool list, filesystem reach, network destinations, and returned fields. A tool executing locally can still return sensitive data to the remote agent loop. Start with one read-only server and reject unexpected tools or oversized responses.
6. Treat computer use as privileged
Use a dedicated desktop session with no personal apps, notifications, password manager, clipboard history, or unrelated browser tabs. Validate the screen-recording boundary before granting input control. Keep manual takeover and an immediate worker-disable path available.
7. Test pool failure and rollback
For Team Pools, exercise worker disconnect, queue saturation, hibernation, reconnect, and a follow-up arriving after the original worker disappears. Record whether requests wait, move to another worker, or fail. Roll back by disabling the canary pool or returning the repository to a managed Cloud Agent policy—not by leaving an unhealthy worker silently available.
Acceptance canaries
worker image / CLI version / OS identity:
workspace roots / repository allowlist:
allowed outbound destinations:
credential scopes and expiry:
local MCP servers and returned fields:
computer-use permissions and desktop account:
data-egress matrix reviewed by:
disconnect / saturation / reconnect results:
artifact and log retention checked:
rollback owner / command / timestamp:
Require evidence for four denial paths: an out-of-root file read, an unapproved internal host, a synthetic credential, and an unapproved MCP tool. A self-hosted label is not a security test.
Decision tree
Does managed Cloud Agent connectivity meet the requirement?
yes -> keep managed isolation
no -> is this personal custom hardware or an enterprise worker fleet?
personal -> use a dedicated My Machine canary
fleet -> require Enterprise Team Pools and service identity
-> map data egress
-> run credential, MCP, desktop, and failure canaries
-> promote one repository cohort
Common mistakes
- Saying all code or data stays inside the network because tools run locally.
- Connecting a personal laptop with broad filesystem, clipboard, and desktop access.
- Reusing a personal API key for Team Pool authentication.
- Assuming a local MCP server's output remains local.
- Granting Accessibility and Screen Recording before isolating the desktop session.
- Ignoring patching, queue capacity, hibernation, and reconnect behavior.
- Choosing self-hosting when managed private connectivity already meets the requirement.
Building something? Turn your product page into a show people want to watch with PromoFast —hosted, embeddable, and ready to export.
FAQ
Does Cursor inference run on my self-hosted worker?
The official architecture says Cursor continues to run the agent loop, inference, and planning. Your worker runs tools such as commands, file edits, local MCP, and optional computer use.
Does the full repository leave my machine?
The full checkout stays on the worker, but selected file contents and other context needed by the agent can be sent to Cursor. Review the actual data flow rather than treating those statements as equivalent.
Are Team Pools available on every plan?
No. Cursor documents Team Pools as an Enterprise feature. My Machines is the personal-worker path.
Top comments (0)