Vercel Hobbyの関数ストレージが100%になった話｜main直pushの本番デプロイ履歴とRetention設定

star-moti の改修ログはサイト改修ハブにまとめています。今回はインフラ側の小トラブルメモです。

Vercelから、無料チーム（Hobby）の 関数ストレージ無料枠（10GB）が100% になった、という通知が来ました。「サイトが成長しています！」みたいな明るい文面だけど、中身は ストレージ満杯アラート。放置すると、新規デプロイが止まったり失敗したりすることがあります。

Vercelから届いた通知メール。関数ストレージ無料枠10GBが100%になった旨と、Proへのアップグレード案内（チーム名はぼかし）

結論から言うと、だいたい main にずっと直接 push し続けて、Production デプロイの履歴が積み上がった のが本体、という理解です。

1. 何が起きたのか？

まず Pro 課金に飛びつく前に、履歴の掃除と保持期間の見直し で足りるか見ました。

Vercel側では、デプロイの出力や関数バンドルの保持がストレージに効きます。Deployment Storage と Functions Storage は別メーターですが、どちらも「残っているデプロイの数 × 1本あたりの大きさ」で積み上がりやすい、という感覚です。

最初は「Previewを消そう」と思いました。Deployments一覧を見ると、しかし 全部 Production に見える。

理由は2つあります。

フィルタで Environment Production が付いていると、Productionしか出ない
× で外すと Preview があれば見える。
star-moti は main 直push運用
記事を出すたびに本番デプロイが作られる。PRプレビューをほとんど使っていないので、履歴の大半が Production。

つまり、「Previewを消す」手順自体は正しいけど、このサイトのストレージ圧迫の主因は 古い本番デプロイの山 の可能性が高い、という話でした。

main に永遠に（というか頻繁に）push し続けた結果、というのはだいたいその理解で合っています(^^;

やり方	向き
古い Production を手で Delete	今すぐ枠を空けたいとき。いまの本番（一番上）は消さない
Deployment Retention Policy を短くする	今後の自動掃除。数が多いときの本命
使ってないプロジェクト削除	チームに別プロジェクトがあるとき
Pro課金	掃除してもすぐ再逼迫するときの検討

手削除は、公式だとだいたい「一覧 → デプロイを開く → ⋯ → Delete」で 1個ずつ になりがち。ブログ運用で履歴が大量なら、Retentionの方が楽です。

設定は Settings を開いて、左メニューの Build and Deployment を選べば そこにあります。ページ内の Deployment Retention Policy が該当ブロックです。

導線のイメージ:

手順:

※ 似た名前の Deployment Protection（アクセス制限）とは別物です。引っかかりやすいので注意。

Build and Deployment 画面。赤い矢印で左メニューの Build and Deployment と、Deployment Retention Policy（1 week / 2 weeks）を示している

ロールバック用に本番履歴を少し残しつつ、ストレージは抑える、というバランスです。

いま本番に紐づいている最新デプロイは残る 想定です。

Retentionは「古い履歴を期限後に消す」仕組みで、動いている本番を落とすためのものではありません。Hobbyだと直近の本番 Ready が数個は例外で残る、といった説明もあります。

消えたあともすぐ全部消えるわけではなく、裏側のジョブで順に処理されることがあります。Usageの数値反映も遅れることがあるので、「保存した瞬間に0%」にはならない、くらいの心づもりでOKです。

同じように「記事を出すたびに main へ push」している個人サイト勢の、備忘録になればうれしいです(^^)