
1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
ステージングコンテナを 1 度だけスナップショット化します。新しい PR ごとに、独自の URL を持つコンテナへスナップショットがクローンされます。レビュアーがリンクを開くとコンテナが起動し、誰も見ていないと昼寝し、PR がクローズされたら 1 行の cron が破棄します。60 ブランチ、60 URL、定額の請求。
右側の URL がプレビュー環境です — ワンクリック、本物のコンテナ、本物のデータベース
3 つの呼び出し。1 行の cron。すでに持っている CI パイプラインが、自分で書くなら同じ順序で呼び出します。
ステージングスタック(アプリ、データベース、キュー、フィクスチャ)を実行するコンテナを選びます。スナップショットを POST し、staging-base と命名。ファイル、プロセス、メモリがキャプチャされます。スナップショットは tarball ではなく、差分対応の出発点であり、クローンはコピーではなくページを共有します。
CI が GitHub プッシュ Webhook を受け取り、source_snapshot=staging-base でコンテナ API に POST します。シードデータベースと PR のブランチがチェックアウトされた状態で、新しいコンテナが数秒で起動。URL はステータスチェックとして返されます。
5 分ごとの cron エントリがマージ済み PR を巡回しコンテナを DELETE します — もしくはマージ Webhook がインラインで実行します。コンテナのディスク差分は回収され、URL は解放され、コンテナのスロットは次の PR のためにプールへ戻ります。
ステップ 02 は yarn install くらいの時間です。ステップ 03 は HTTP コール 1 回。PR のコンテナが存在したことを他の誰かが知る必要はありません。
Hoody Containers と Snapshots API の実エンドポイント 3 つ。すでにある GitHub Actions ステップに差し込んでください。
/api/v1/containers/[staging_id]/snapshotsBody: [ "alias": "staging-base", "expiry": 30 ]。snap-20260501-093000 のようなスナップショット名を返します。main ブランチデプロイごとに 1 度実行 — すべての PR クローンは最新キャプチャから派生します。
/api/v1/projects/[project_id]/containersBody は server_id と container_image を選び、PR 番号、ブランチ参照、データベース名を注入するため environment_vars を渡します。コンテナはゼロからではなく、スナップショットのファイルシステムから起動します — キャッシュやシードデータはすでにそこにあります。
/api/v1/containers/[pr_container_id]1 つの呼び出し。コンテナがシャットダウンし、ディスク差分が回収されます。それ以外に分解する必要はありません。誰も見ていない間にクローズされた PR は、5 分間隔の cron エントリが処理します。
Hoody Container Snapshots API および Containers API のエンドポイントです。スナップショットの有効期限は日数指定。コンテナ作成は environment_vars、ssh_public_key、autostart、ramdisk、realm_ids を受け付けます — 完全なリクエストスキーマはドキュメントを参照してください。
計算がレビュアーの行動を制限しなくなります。プレビュー 1 つ $40 では高すぎた 3 つの習慣が、PR ごとのコストが端数誤差になると自然に現れます。
バグ再現のためにブランチをローカルにチェックアウトする人はいません。URL を開いて壊れているところをクリックし、PR にスクリーンショットを残します。レビュールーフは差分が示唆するものではなく、コードが実際に行っていることに基づいて回ります。
今レビューされていない 50 件の PR は、CPU ゼロ、RAM ゼロ。staging-base スナップショットのページをディスク上で共有するため、フットプリントもほとんど差分のみ。請求は PR の数ではなく、ボックスで上限が決まります。
デザイナー、サポートエンジニア、セールスリード — URL を持つ誰もが PR を試せます。彼らがブランチを git checkout することはなかったでしょう。リンクがあれば、リリース前に変更を実際に見るようになります。
月に 30 PR を開くチーム。以前の数字は標準的なプレビュー環境の請求額。以後の数字は、30 件全部とステージングが収まる Hoody ベアメタル 1 台です。
$480/月
シート単位の Pro 価格に加え、ビルド分数と帯域幅。月 30 PR デプロイをこなす 6 人エンジニアチームの場合。ほとんどのチームは次の 20 件が本当にお金になるため、アクティブな 10 件にプレビューを制限します。
$30/月
Hoody マーケットプレイスのミッドティアサーバー 1 台がステージング、30 件の PR クローン、CI キャッシュをまかないます。次の 60 件は $0 で追加できます — コピーオンライトにより、各クローンはスナップショットのページに差分が加わるだけです。
Vercel Pro の表示価格はシートあたり月 $20 + 使用量。Hoody ベアメタル価格はマーケットプレイス主導で、エントリーティアは月 $20 未満から。コンテナ密度はワークロード次第 — 一般的な Web アプリは数十〜数百個収まります。大規模なステートフルサービスはより余裕が必要です。
プレビュー環境は予算項目ではなくなり、デフォルトになります。
プレビュー環境製品はシート単位、分単位、または稼働中コンテナ単位で価格を設定します。Hoody はサーバー単位 — 30 番目のプレビューは 1 番目と同じコストです。
1 度スナップショット。PR ごとにクローン。マージで破棄。レビュアーは継ぎ目を感じません。