跳转到内容
use-cases / preview-env-per-pr-cheap / hero
CONTAINERS · SNAPSHOTS · PR PREVIEWS

每个 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 个容器
use-cases / preview-env-per-pr-cheap / mechanism

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 的容器存在过。

use-cases / preview-env-per-pr-cheap / api

你的 CI 实际调用的端点

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

预览环境 · 调用表containers + snapshots
  • 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 见文档。

use-cases / preview-env-per-pr-cheap / powers

预览免费后会改变什么

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

审阅速度

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

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

预算

闲置 PR 不产生费用

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

设计与产品

干系人加入循环

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

use-cases / preview-env-per-pr-cheap / compare

把美元数算清楚

一个团队每月开 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 应用每台机器装数十到数百个;大型有状态服务需要更多余量。

use-cases / preview-env-per-pr-cheap / punchline

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

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

本方案替代了什么

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

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

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

阅读快照指南
use-cases / preview-env-per-pr-cheap / related

阅读其他内容