跳转到内容
类型解锁
阶段船队
难度中等
工作分支环境
用于开发团队
服务容器
服务快照
为何选 Hoody容器经济学
为何选 Hoody快照时间旅行
类型解锁
阶段船队
难度中等
工作分支环境
用于开发团队
服务容器
服务快照
为何选 Hoody容器经济学
为何选 Hoody快照时间旅行
类型解锁
阶段船队
难度中等
工作分支环境
用于开发团队
服务容器
服务快照
为何选 Hoody容器经济学
为何选 Hoody快照时间旅行
类型解锁
阶段船队
难度中等
工作分支环境
用于开发团队
服务容器
服务快照
为何选 Hoody容器经济学
为何选 Hoody快照时间旅行
返回使用场景列表
容器 · 快照 · PR 预览

每个 PR 一个预览环境，整月

给预发布容器拍一次快照。每个新的 PR 把快照克隆到自己的容器里，带自己的 URL。审阅者打开链接时容器唤醒，无人查看时打盹，PR 关闭时被一行 cron 销毁。60 个分支，60 个 URL，一张固定账单。

阅读快照文档
CRON · 销毁已合并的预览一行命令，每 5 分钟一次
# 当 PR 合并时，cron 销毁其容器。*/5 * * * * curl -X DELETE https://api.hoody.com/api/v1/containers/$MERGED_PR_CID
快照血统一个基础 · 多个克隆
STAGING-BASEsnap-2026-05-01 · 4.2 GB
写时复制页共享30 / 30 个容器

PR 是如何变成 URL 的

三个调用。一行 cron。你已经有的 CI 流水线按你自己也会写的顺序触发它们。

    01
    步骤 01 · 一次

    给预发布容器拍快照

    选中跑你预发布技术栈的容器——应用、数据库、队列、fixture。POST 一次快照，命名为 staging-base。文件、进程、内存全部被捕获。这份快照是一个可增量的起点，不是 tarball——克隆共享它的页，而不是复制。

    02
    步骤 02 · 每个 PR

    推送时克隆快照

    你的 CI 收到 GitHub 推送 webhook，带 source_snapshot=staging-base 调用容器 API。一个新容器在几秒内启动，带着已填充的数据库和已检出的 PR 分支。URL 作为状态检查回传。

    03
    步骤 03 · 合并时

    PR 关闭时销毁

    一条 5 分钟的 cron 条目遍历已合并的 PR 并 DELETE 它们的容器——或者由你的合并 webhook 直接处理。容器的磁盘增量被回收，URL 被释放，容器槽位回到池中等待下一个 PR。

步骤 02 大约和一次 yarn install 耗时相当。步骤 03 是一次 HTTP 调用。其他东西都不必知道这个 PR 的容器存在过。

你的 CI 实际调用的端点

三个来自 Hoody Containers 和 Snapshots API 的真实端点。把它们丢进你已经有的 GitHub Actions 步骤里。

预览环境 · 调用表容器 + 快照
  • POSTmethod · path
    /api/v1/containers/[staging_id]/snapshots

    捕获 staging-base 快照

    Body: [ "alias": "staging-base", "expiry": 30 ]。返回类似 snap-20260501-093000 的快照名。每次主分支部署运行一次——每个 PR 克隆都派生自最近一次捕获。

  • POSTmethod · path
    /api/v1/projects/[project_id]/containers

    为每个 PR 克隆一个全新容器

    Body 选定 server_id 和一个 container_image；通过 environment_vars 注入 PR 编号、分支引用和数据库名。容器从快照的文件系统启动，而不是从零开始——缓存和种子数据都已就位。

  • DELETEmethod · path
    /api/v1/containers/[pr_container_id]

    PR 关闭时下线预览

    一次调用。容器关闭，磁盘增量被回收；不需要再拆任何其他东西。一条 5 分钟节奏的 cron 处理那些没人盯着就关掉的 PR。

端点来自 Hoody Container Snapshots API 和 Containers API。快照过期时间以天为单位；容器创建接受 environment_vars、ssh_public_key、autostart、ramdisk 和 realm_ids——完整请求 schema 见文档。

预览免费后会改变什么

成本不再绑住审阅者的手脚。三种在每个预览要 40 美元时太贵的习惯，在每个 PR 的成本变成零头后会自动出现。

审阅速度

审阅者点链接，不再拉分支

没人会再 checkout 分支到本地复现 bug。他们打开 URL，点一下出问题的地方，在 PR 里留张截图。审阅循环跑在代码实际行为上，而不是 diff 看起来像什么。

预算

闲置 PR 不产生费用

当下没人在审阅的那 50 个 PR 占用零 CPU 和零 RAM。它们在磁盘上共享 staging-base 快照的页，所以连占用空间也基本只是增量。账单上限取决于机器，不是 PR 数量。

设计与产品

干系人加入循环

你的设计师、你的支持工程师、你的销售负责人——任何拿到 URL 的人都能戳一下 PR。他们本来就不可能 git checkout 一个分支。有了链接，他们才真的会在改动落地前看一看。

把美元数算清楚

一个团队每月开 30 个 PR。之前的数字是常规的预览环境账单。之后的数字是一台 Hoody 裸金属机器，装下全部 30 个加上你的预发布。

之前 · VERCEL PREVIEWS, PRO TEAM

$480/月

按席位的 Pro 价格加上构建分钟数加上带宽，适用于一个 6 人工程师团队、每月 30 次 PR 部署。大多数团队会把预览限制在最活跃的 10 个，因为接下来 20 个是要花真金白银的。

VS
之后 · HOODY · 一台裸金属机器

$30/月

Hoody 市场上的一台中档服务器跑预发布加 30 个 PR 克隆加你的 CI 缓存。再来 60 个是 0 美元——写时复制意味着每个克隆都是快照的页加一个增量。

Vercel Pro 标价为每席位每月 20 美元加用量；Hoody 裸金属入场价格起价 $29/月，根据规格、区域和租期变化。容器密度取决于工作负载——典型 Web 应用每台机器装数十到数百个；大型有状态服务需要更多余量。

预览环境不再是一项预算。它们成了默认值。

之前 · 限定在最活跃的 10 个之后 · 每个 PR 一个
旧策略长什么样只为最显眼的 10 个 PR 做预览另外 20 个在评论里贴张截图
现在长什么样每个 PR · 每个 diff · 每个审阅者没有策略文档，没有为预览申请的工单
查看快照文档

本方案替代了什么

预览环境产品按席位、按分钟或按运行容器计费。Hoody 按服务器计费——第 30 个预览的成本和第 1 个一样。

  • Vercel 预览环境（Pro / Enterprise）按席位加构建分钟数加带宽
  • GitHub Codespaces 预览无论审阅者看不看，都按小时计费
  • AWS Fargate 预览任务每个任务按 vCPU + 内存小时计费，加数据传输
  • Render 预览环境按环境计费，闲置不免费
  • Heroku review apps每个 PR 一个 dyno，每次审阅按 dyno 小时计
  • Netlify deploy previews + 构建分钟数构建分钟数计的是每次推送，不是每次审阅

拍一次快照。每个 PR 克隆一份。合并时销毁。审阅者完全感知不到接缝。

阅读快照指南

阅读其他内容