Skip to content
FunCoding

Search

Search docs, Skills and MCP

自托管平台与模板

选择 Team Pool 基础设施,识别参考部署责任与已弃用 Kubernetes Operator。

This page has not been translated into English yet. The original Chinese version is shown below.

不同托管平台运行同一种 Team Pool worker:Cursor CLI 主动建立出站 HTTPS 连接,Cursor 经连接发送工具调用。合作伙伴教程和官方模板是参考架构,镜像、秘密、扩容与生产验证仍由部署方负责。

接入前提

需要 Enterprise,并由团队管理员开启 Self-Hosted Machines。Worker 用 CURSOR_API_KEY 中的服务账号 key 认证;通过 pool 名称或 labels 路由请求。

允许出站 HTTPS 到 api2.cursor.sh、api2direct.cursor.sh 和 cloud-agent-artifacts.s3.us-east-1.amazonaws.com。先手动启动一个 worker 验证,再接入自动控制器。单台个人电脑场景使用 My Machines,不必为它套用团队池架构。

官方参考模板

模板扩容单位
anysphere/aws-lambda-workers--spawn 为每个 claim 启动 Firecracker 隔离的 Lambda MicroVM
anysphere/cloudflare-workersCloudflare Worker 作 controller,每个 claim 启动一个 Container
anysphere/k8s-workersHelm 示例运行 agent worker controller --spawn,每个 claim 一个 Pod,也可用 --warm-idle 保留空闲 Pod

新的 Kubernetes 示例不依赖 CRD。旧 Cursor Kubernetes operator 和 WorkerDeployment Helm chart 已弃用,既有集群仍可使用对应参考,但新部署不应从它起步。

平台选择

官方目录还列出 AWS Lambda、Cloudflare、Namespace、Modal、Daytona、E2B、Vercel、Tensorlake、Coder 和 Superserve 的合作伙伴指南。只在选定平台后依据其当前文档补足镜像构建、网络和生命周期;本文不把某一个平台的启动参数推广到其他平台。

Worker controller 的 claim、spawn 和回收详见控制器,认证与路由见Team Pools。