Vercel のデプロイメントストレージを 13.96 GB から 20.27 MB に減らす — プレビュー停止と保持期間の短縮
Vercel の Hobby プランでデプロイメントストレージの上限 10 GB を超えました。原因はビルド1回 147 MB × 30日間で 189 回というデプロイ回数でした。
目次
はじめに
Vercel の使用状況ページで、Deployment Storage に赤いリングが付いていました。無料枠 10 GB に対して 13.96 GBが使われています。他の項目はどれも上限の 20% に届いていません。
最初に気になったのは、公開中のサイトに影響が出るかどうかでした。影響はありませんでしたが、超過したままにすると代償はあります。Vercel は 30 日の保持期間を適用しなくなり、対象のデプロイを即座に削除しますし、上限を下回るまで新しいデプロイを拒否することもあります。
まず疑ったのはリポジトリでした。この記事も含めて、どの記事にも図やスクリーンショットが入っています。しかしリポジトリはパック後で 9.79 MiB、画像と動画を全部足しても 9.4 MB です。このサイトのビルド1回分は 147 MB で、それが 30 日間に 189 回作られていました。
プレビュービルドを止め、保持期間を1日に縮め、リリースフローの先頭に整理を1手入れたところ、同じグラフが 20.27 MB になりました。
クォータの読み方: ビルド 147 MB 対リポジトリ 9.79 MiB
Deployment Storage が測っているのはデプロイごとに保持されるビルド出力で、このサイトではそれを生成したリポジトリの約 15 倍あります。
どちらもコマンド1本で出ます。
入力git count-objects -vH | grep size-pack出力size-pack: 9.79 MiB入力du -sm .vercel/output出力147 .vercel/outputクォータが数えているのは後者です。.vercel/output は vercel build が生成し vercel deploy --prebuilt がアップロードするもので、デプロイ側のファイル数は 2847、ローカルは 2843 で、転送中に実質的なものは増えていません。
147 MB の内訳
デプロイの半分はサーバーバンドルで、そのうち 20 MB は同じバンドルをもう一度収めたものです。
static/_astro は3言語分の画像派生ファイル 893 個です。_render.func の中には 29 MB の node_modules が入っています。Astro のサーバーランタイムと、記事ページがレンダリング時に読み込むもの一式です。static/_astro は Astro が処理済み画像を書き出す場所で、893 個という数は同じ元画像から作られた3言語分の派生ファイルです。
画像を外部に移しても 6% にしかならない理由
このリポジトリにコミットされている画像と動画は合計 9.4 MB です。オブジェクトストレージに逃がしても、デプロイ1回分の 16 分の 1 にしか効きません。
入力find src -type f \( -name '*.mp4' -o -name '*.png' -o -name '*.jpg' -o -name '*.webp' -o -name '*.avif' \) -exec du -ch {} + | tail -1出力9.4M totalクォータが数えているのは static/_astro の方で、その派生ファイルはビルド時に元画像から生成されます。元画像をバケットから配信しても、git から 9.4 MB が出ていくだけで、33 MB の派生ファイルはそのまま残ります。
147 MB を半分にしたところで、占有する容量はデプロイ回数に応じて積み上がり続けます。デプロイ1回あたりのサイズを管理しても、問題は解決しません。
30 日間で 189 回のデプロイ
ストレージはビルドサイズ × デプロイ回数で、誰も見ていなかったのは回数の方でした。
GitHub はデプロイごとに記録を残すので、回数は Vercel ではなくリポジトリ側から取れます。
gh api "repos/<owner>/<repo>/deployments?per_page=100" --paginate直近 30 日を作成者別に集計すると、vercel[bot] が Preview 環境に作ったものが 122 件、このリポジトリの CI が production に作ったものが 67 件でした。
1回 147 MB として、189 回のデプロイは 10 GB の枠に 1 か月で 27.8 GB を流し込んだことになります。
誰も開かなかったプレビュー 122 件
デプロイの3分の2は、すでにマージされて削除されたブランチのプレビューでした。そしてそのすべてが自動で作られたものです。
超過した時点でまだ残っていた4件が理由を示しています。どれもそのブランチの最新プレビューで、どのブランチも squash マージ後に削除済み、git ls-remote --heads origin にはひとつも出てきません。
Vercel はアクティブなブランチの最新プレビューを残す仕様ですが、これらのブランチがすでに消えていることは把握していませんでした。
プレビュー停止、保持期間の短縮、そして整理
設定は3つで、それぞれ積の別の項に効きます。デプロイが作られる頻度、保持される期間、そしてすでに溜まっている数です。
Git 連携を止める
Vercel の Git 連携は、デフォルトでは push のたびに、ブランチを問わずデプロイを1件作ります。そのデプロイ1件ごとに Deployment Storage を 147 MB 占有します。
このサイトにそれらは必要ありません。本番は GitHub Actions がデプロイしており、他のブランチのデプロイも要らないからです。
{ "git": { "deploymentEnabled": false }}これで main を含むすべてのブランチについて、Git 連携が自前で作るデプロイが止まります。
保持期間は Project Settings のドロップダウン4つ
保持期間の設定は Vercel のダッシュボード、Project Settings の Build and Deployment にある Deployment Retention Policy にあります。このアカウントのプロジェクトはどれもプランの初期値のままでした。
| デプロイの種類 | 変更前 | 変更後 |
|---|---|---|
| Canceled | 30 日 | 1 日 |
| Errored | 30 日 | 1 日 |
| Pre-Production | 30 日 | 1 日 |
| Production | 30 日 | 1 日 |
30 日は Hobby プランの最大値なので、初期値がそのまま一番削除の遅い設定でもあります。4つとも最短に変更しました。
Pre-Production Deployments の行です。保持するデプロイ件数を指定する項目はここにはありません。Hobby プランでは vercel usage から何も読めません。
入力pnpm dlx vercel@58 usage出力Error: Billing cost data is unavailable for 2026-09-01 through 2026-09-21.Hobby プランには課金記録がないので、CLI には読むものがありません。GB の数字はダッシュボードにしか存在しません。
--safe が守るものと、消すもの
vercel remove <project> --safe はデプロイを消します。--safe を付けない同じコマンドはプロジェクトを消します。
入力pnpm dlx vercel@58 remove oharu-tech-blog --safe --yes出力> Found 8 deployments for removal in oharu121s-projects [1s]> Success! Removed 8 deployments [909ms]--safe はエイリアスを持つデプロイを対象外にするので、ブランチのエイリアスを持ったままのプレビュー4件も一緒に残りました。
--safe が消した8件と、残した4件。プレビューのブランチエイリアスは、指している当のブランチより長く生き残るので、2回目はデプロイを個別に指定します。このプロジェクトにあった 13 件のうち、1回目で8件が消えて5件残りました。稼働中の本番デプロイと、すでに存在しないブランチのエイリアスを持ったままのプレビュー4件です。この4件は git ls-remote で確認してから URL 指定で消しました。
入力pnpm dlx vercel@58 remove <url> <url> <url> <url> --yes出力> Found 4 deployments for removal in oharu121s-projects [934ms]> Success! Removed 4 deployments [731ms]リリースのどこで整理するか
整理はリリースの先頭で走らせます。末尾で走らせると、本番が変わったその瞬間に、ロールバック先になるはずのデプロイを消してしまうからです。
13.96 GB から 20.27 MB へ
この数字は、3つをまとめて実施した結果です。Git 連携の自動デプロイを止め、保持期間を4種類とも1日にし、溜まっていた分を vercel remove で消しました。
まとめ
デプロイメントストレージはビルドサイズ × デプロイ回数で、読み違えやすいのは回数の方です。このアカウントには 10 個のプロジェクト、稼働中のデプロイ 185 件、147 MB のビルドがあり、リポジトリは合計に影響しないほど小さいものでした。
ストレージの問題かリポジトリの問題かは、3つの確認で分かれます。du -sm .vercel/output がデプロイ1件のサイズを出し、プラットフォーム側のデプロイ記録が回数を出し、その積を枠と突き合わせれば、デプロイを小さくするのか回数を減らすのかが決まります。
回数が問題なら、設定は3つです。新しく作られる分を止めるのが git.deploymentEnabled: false、古い分を落としていくのが保持ポリシー、すでに溜まった分を消すのが vercel remove --safe。今日その場で空くのは最後の1つだけで、しかもそれはリリースの末尾ではなく先頭に置くものです。
