AIREITER大量 AI 生成的应用最终都停在 localhost，Cursor 想解决的正是从本地原型到可访问链接之间的那一步。结合其 更新日志、官方文档以及早期用户提出的问题来看，11 月 5 日发布的 Build Live Apps 很适合通过 Cursor SSO 使用的内部工具和原型；但对于架构复杂、受合规约束的生产后端，目前还不够成熟。
Build Live Apps 到底交付了什么
Build Live Apps 是一套由云端代理驱动的工作流：用自然语言描述需求，代理生成 Web 应用并完成部署。Cursor 在 2026 年 11 月 5 日的更新日志中公布了该功能，Apps 文档描述的流程也一致：向云端代理发出提示词，在托盘中预览，选择 URL，通过安全检查后发布为可访问的链接。
提示词必须说清楚意图。Cursor 文档要求用户明确让代理构建一个应用。你可以在 Cursor Origin 上从零开始，平台会创建新仓库；也可以使用已有的 GitHub 仓库，由 Cursor 负责部署。只有云端代理能构建应用。
需要持久化存储时，Cursor 会配置一套 PostgreSQL 数据库。应用托管在每位用户或每个团队专属、隔离的托管账户中。团队应用使用 Cursor SSO 认证，访问者必须先登录 Cursor 才能打开应用。个人套餐用户则可以发布无需登录的公开应用。
有些限制从第一天起就需要留意：GitLab 支持虽已规划，但尚未上线；自定义域名也尚未得到确认。Cursor 表示发布者可以选择唯一域名，文档还称 URL 后续可修改，但两处都没有展示自定义域名的配置流程。
官方页面也未列出支持的框架、运行时、区域、Postgres 版本、备份、扩缩容机制、带宽配额或 SLA。托管服务在法律上独立于 Cursor 服务，并按 “as is” 和 “as available” 的条件提供；Cursor 保留撤销或暂停子域名及应用的权利。
发布前必须过的关：4 项硬性检查，加一道 AI 审查
应用不会因为准备完成就自动上线，用户必须明确执行发布操作。每次发布都会运行 4 项不可关闭的检查；即使团队关闭额外的 AI 审查，这些检查依然有效：
- 应用文件中发现 API 密钥或访问令牌时，阻止发布。
- 检测并阻止私钥、服务账号密钥等凭据文件。
- 从发布包中排除
.env文件。 - 移除 source map，避免访问者在浏览器中还原原始源码。
检查失败后，Cursor 会列出问题，用户可以让代理修复后重新尝试发布。
额外的 AI 安全审查会读取应用文件，并可在发布前拦截严重问题。团队管理员可以为该审查提示词补充组织特定的指令。自定义指令可以增加规则，但不能移除或削弱 Cursor 内置检查。管理员可以覆盖部分发布拦截，不过涉及恶意代码、硬编码密钥或暴露凭据的拦截无法覆盖。对这些设置的修改会记录到团队审计日志中。
更重要的是，这道发布闸门无法证明什么：
“问题在于：通过安全检查，并不能证明应用只让正确的人获得正确的访问权限。”—— @0node0，真实用户
Cursor 明确举出的检测对象是密钥和暴露的凭据，但并未表示每个应用都会接受授权测试、行级权限测试、SQL 注入覆盖、依赖扫描或业务逻辑审查。TechRepublic 在 11 月 6 日的分析也指出了同一点：应使用不同权限级别的多个账号测试，因为官方没有说明是否会覆盖“一个已认证用户读取另一个用户记录”的问题。
用户最常问的三件事：费用、Vercel 与密钥
托管要额外收费吗？ Cursor 尚未公布独立的托管或数据库价格。Build Live Apps 没有单独订阅，包含在具备云端代理访问权限的付费套餐中。目前能确认的具体价格来自 TechRepublic 的套餐表，而不是 Cursor 的功能页面：
| 套餐 | 标价 | Build Live Apps 访问权限 |
|---|---|---|
| Plus | $8/month | 否，不提供云端代理 |
| Premium | $30/month | 是，符合条件的最低个人套餐 |
| Super | $100/month | 是，使用额度更高 |
| Ultra | $200/month | 是，列出的额度最高 |
| Team | From $30/user/month | 是，额外提供管理员控制功能 |
| Enterprise | Custom | 是，取决于策略 |
Cursor 使用共享的每周 AI 用量额度，详见 TechRepublic 的套餐拆解；但 Cursor 没有在这些页面中披露各档的 token、请求数或算力数值。第三方模型可能产生单独费用，TechRepublic 亦有提及。数据库、存储、流量和并发限制同样未说明。因此，$30 应被视作使用门票，而不是完整运营成本；在将面向客户的工作负载放到内置托管前，应先确认配额。
Build Live Apps 能替代 Vercel 吗？ 对于复杂或合规敏感的生产后端，目前还不能。内置方案适合 PostgreSQL、SSO 和分享链接这一组合。涉及自定义架构或受监管数据时，仍应采用 GitHub 配合 Vercel、Netlify、Railway、Render 或 VPS 的传统路径；下表给出了按场景划分的完整建议。Reddit 上关于托管的讨论反复回到同一判断标准：工作负载的状态性和长期运行需求，决定了该选什么托管方案。
“我时间线里看到的大多数 Cursor 演示都聚焦在 UI……多数并没有部署给真实的付费用户。”—— @mayowaoshin，真实用户
密钥存在哪里，代理能看到吗？ Cursor 文档明确说明，编码代理永远看不到密钥值。应用需要数据仓库或外部 API 时，系统会要求用户提供密钥。团队密钥通常由团队管理员在 Apps 控制台创建，也可以之后通过同一控制台添加。
团队管理员可以查看所有团队应用和团队密钥。这既是治理能力，也是粘贴生产密钥前需要理解的信任边界。脚本、CI 作业和 Grok Bot 等自动化客户端访问受保护应用时，使用基于请求头的密钥 x-cursor-app-token，而不是 Cookie 或查询参数。
哪些场景适合内置托管，哪些该坚持传统部署
| 场景 | 内置 Live Apps | 传统部署（Vercel / Railway / VPS） |
|---|---|---|
| SSO 保护的内部仪表盘、报名跟踪器、入职门户 | 最适合，可最快获得分享链接 | 除非应用超出配额，否则属于过度配置 |
| 带邮件表单的公开营销微站 | 个人套餐可通过公开分享实现 | 若需要自定义域名、分析或边缘缓存，应走传统路径 |
| 需要 Postgres、Cursor SSO 与管理员下线能力的应用 | 原生支持，具备隔离托管账户、明确发布流程和审计日志 | 需手动重建认证、数据库和审查闸门 |
| 自定义认证、超出 Cursor 范围的 SAML/OIDC、重度依赖 RLS 的 Supabase schema | 风险较高，管理员可见密钥，权限模型尚未被验证 | 应走传统路径，自行掌控认证和数据层 |
| 长期运行的后端、worker、cron、WebSocket、非 Postgres 存储 | 官方未说明，缺少运行时和扩缩容规格 | 只要需要其中任何一项，就应走传统路径 |
| GitLab 源码、本地代理工作流、受监管的数据驻留/SLA | 不适用：仅支持 GitHub 或 Origin、云端代理及按现状提供的托管 | 应走传统路径 |
| 生产环境支付、webhook、PII | 仅适合试点；通过检查后仍须独立验证授权 | 应采用带预发布环境、分支保护和受限密钥的传统路径 |
传统路径也保留了自己的配置工作：MCP 配置、托管凭据、环境变量和 RLS 加固。一位开发者从落地页到 Vercel，再到 Supabase 认证所走的四周路径，正好说明了这一点。
分享前先过一遍：生产就绪检查清单
Cursor 的检查能拦住泄露的密钥和凭据文件，但权限、环境配置、异步副作用以及无人审阅的代码，仍是剩余风险。即便只是内部工具，首次分享前也应完成以下检查。
- 从干净环境重新构建，并审阅 diff。让代理运行真正的生产构建，而不是开发服务器。逐个打开付款、认证和数据写入相关的改动文件。如果项目已经膨胀到无法审阅 diff，不要继续在混乱代码上追加提示词；应恢复检查点并拆分任务。
- 用两个账号测试权限。分别以管理员和受限成员身份登录。用用户 A 创建记录，再尝试让用户 B 读取、编辑和删除它。安全报告通过，并不能证明行归属逻辑正确。
- 端到端审计密钥。确认没有密钥被打包进前端代码，没有
.env被发布，并且每项外部凭据都采用仍能正常工作的最小权限范围。将生产数据库直连 URL 从代理可访问的环境中移除。一则 r/cursor 报告称，Cursor 曾直接部署到生产 Supabase，而不是经由 GitHub。 - 压测异步链路。触发真实 webhook，重试它，并在执行中途终止它。检查并发使用下的连接池表现。用户表示，静默失败的 webhook 和耗尽的连接池，往往要等上线后才会暴露。
- 明确更新与回滚流程。确认谁能发布、谁能覆盖被拦截的发布、谁能下线应用，以及审计日志存放在哪里。记录错误发布如何回退、schema migration 如何执行，因为文档描述了发布，却没有说明版本历史或回滚机制。
“应用一旦离开 localhost，它的密钥也会随之离开。”—— @1PasswordDev，讨论按应用隔离密钥的真实用户
如果上面任何一步没有答案，例如没有预发布项目、没有第二个测试账号，或没有回滚方案，就应继续将应用限制在团队专用链接中，或保留在传统技术栈上，直到补齐这些能力。
FAQ
Build Live Apps 是否需要付费 Cursor 套餐？
需要。Build Live Apps 仅适用于已启用云端代理的付费套餐。$8/month 的 Plus 不符合条件，$30/month 的 Premium 是符合条件的最低个人套餐。
Cursor 能基于现有仓库构建应用吗？
可以，支持已有 GitHub 仓库，也支持在 Cursor Origin 上从零开始。GitLab 已在规划中但尚不可用，本地代理也不能构建应用。
团队应用可以公开吗？
Team 和 Enterprise 套餐默认关闭公开分享。管理员可在 Apps 控制台中开启。个人套餐则可以直接发布公开应用。
Cursor 支持自定义域名吗？
Cursor 表示发布者可选择唯一域名，并能在之后修改；但更新日志和文档均未确认自定义域名映射。除非 Cursor 另行说明，否则应默认使用 Cursor 管理的 URL。
脚本或机器人如何访问私有应用？
配置 Cursor API 密钥，并在每个请求中以 x-cursor-app-token 请求头发送。个人密钥可打开密钥拥有者有权访问的任何应用；团队密钥则只能打开被明确授权的团队应用。
下线应用后会发生什么？
管理员可以下线任何团队应用；关闭公开应用后，已有公开应用会恢复为仅团队可见。Cursor 未说明下线后的数据保留、备份或导出行为。
Build Live Apps 消除了从可运行原型到可用链接之间的托管配置工作，但它并没有免除代码审阅、权限测试和责任归属这些决定他人能否安全使用应用的工作。
延伸阅读： Best LLM for Coding Agents 2026 · Cursor Projects Beta Review · Cursor Router Explained