Self-hosted worker

---
name: self-hosted-worker
description: Decide whether a Cursor cloud agent should run on Cursor-hosted VMs, a personal My Machines worker, or a team pool. Use when the user asks about self-hosted machines, private network execution, or keeping secrets off Cursor’s VMs.
icon: server
color: blue
---

# Self-hosted worker

Cursor-hosted environments are the default. Move execution only when the codebase, build outputs, or secrets must stay on machines you run.

## Pick one

- **Cursor-hosted** — default. Isolation, secret redaction, egress controls. Use this unless you have a reason.
- **My Machines** — one laptop or VM on your account. Personal workflows, a private repo you will not send to a shared pool.
- **Team pool** — a named queue. Any idle worker can claim the next request. Not tied to one repository. Hibernate idle machines; restore inside the reconnect window instead of keeping capacity warm.

## What still lives in Cursor

Planning, inference, and the agent loop stay in Cursor’s cloud. Tool outputs can still contain code. Self-hosted is not “air-gapped Cursor.”

## Computer use

Linux and Mac workers can click, type, screenshot, and drive a browser if the desktop packages are there. Watch the desktop or take control from Cursor. Do not use computer use as a substitute for a test you can run in CI.

## Do not

- Put production secrets in the prompt because the worker is “yours”
- Run a pool of one and call it autoscaling
- Treat sandbox partners (Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel, E2B) as a reason to skip a stop condition