在基础设施合作伙伴的平台上运行团队用量池 worker，或从参考模板入手，克隆后自行调整。无论哪种选项，运行的都是同一个 worker：Cursor 命令行界面向 Cursor 发起一条出站 HTTPS 连接，Cursor 通过该连接发送智能体工具调用。
合作伙伴指南和模板均为参考架构。worker 镜像、基础设施、机密信息、伸缩策略以及生产环境验证均由你负责。
合作伙伴指南¶
各合作伙伴均维护自己的指南，介绍如何在其平台上运行自托管机器 worker：
- AWS Lambda. Cursor Self-Hosted Machines on Lambda MicroVMs
- Cloudflare. Cursor Cloud Agents on Cloudflare Sandbox
- Namespace. Cursor integration
- Modal. Cursor on Modal
- Daytona. Cursor Self-Hosted Machines on Daytona
- E2B. Cursor agents on E2B
- Vercel. Cursor with Vercel Sandbox
- Coder. Agent Relay for Cursor
参考模板¶
克隆以下任一仓库，即可基于已可运行的 worker 部署开始。每个仓库都会运行一个 worker controller，用于认领待处理用量池请求，并为每次认领启动一个 worker：
- AWS Lambda MicroVMs. anysphere/aws-lambda-workers：
--spawn钩子会为每个 claimed request 启动一个由 Firecracker 隔离的 Lambda MicroVM。 - Cloudflare Containers. anysphere/cloudflare-workers：由 Cloudflare Worker 充当 controller，为每个 claimed request 启动一个 Cloudflare Container。
- Kubernetes. anysphere/k8s-workers：一个 Helm 示例，在你的 cluster 中运行
agent worker controller --spawn，无需 CRD 即可为每个 claimed request 创建一个 Pod，或通过--warm-idle保持若干空闲的热备 Pod。新部署请采用这一 Kubernetes 方式。
Cursor Kubernetes operator 和 WorkerDeployment Helm chart 已弃用。已在运行
operator 的 cluster 可继续使用；operator 参考
仍会为其保留。请不要在其上开始新的部署。
每个 integration 都需要什么¶
平台各不相同，但对 worker 的要求始终一致：
- 一个 Cursor 企业版方案，并由 team admin 在 Cloud Agents 仪表盘中启用 自托管机器。
- 在
CURSOR_API_KEY中配置 service account API key。参见认证 worker。 - 可向
api2.cursor.sh、api2direct.cursor.sh和cloud-agent-artifacts.s3.us-east-1.amazonaws.com发起出站 HTTPS 连接。参见网络。 - 一个 用量池 名称或若干 labels，以便 Cursor 将相应的 requests route 到该平台上的 worker。
如果只有一台个人 machine，而非由平台 managed 的 fleet，请使用我的机器。
后续步骤¶
- 团队用量池：在平台上实现自动化之前，先手动启动一个 团队用量池 worker。
- Worker controller：所有 参考模板 都基于的
--spawn钩子模型。 - Kubernetes operator (已弃用) ：适用于已运行
WorkerDeploymentoperator 的 cluster 的参考内容。 - API 参考文档：worker、团队用量池、待处理请求队列和 worker token 相关的端点。
