Vercel · Vercel Deployment Storage

Deployment 是什么

Vercel 每次部署都会生成一条独立的 Deployment，对应这次部署产生的实际产物，并为其分配独立的访问地址，例如：https://<domain>-kfqiciq3o-<project-id>-projects.vercel.app。

可以把一条 Deployment 理解为一次快照：用于回滚到指定版本、查看某个版本的具体内容，以及排查历史版本的问题。

以 Next.js 项目为例，构建（Build）完成后产物会输出到 out 目录，这就是该次部署的构建输出，Vercel 会把它保存到 Deployment Storage 中。

这些文件会占用存储空间并产生存储成本，因此 Deployment Storage 存在用量限制。

Hobby 存储限制

Hobby Team 的 Deployment Storage 上限为 10 GB。超出上限后，在释放出存储空间之前，新的部署会被阻止。

Vercel 会根据 Deployment Retention Policy 自动清理到期的历史 Deployment，同时保留部分特殊 Deployment，例如最近创建的若干次部署、当前 Production、带有 Alias 的部署，以及仍处于活动状态的 Git 分支上的最新 Preview Deployment。

查看

在 Vercel Dashboard 中，通过 Usage 面板可以快速查看所有 Project 的 Deployment Storage 用量。例如 1.39 GB / 10 GB 表示所有 Project 的构建产物总共占用了 1.39 GB。

也可以进入某个 Project，在 Overview 中查看。

删除

进入某个 Project 的 Deployment 列表，打开某次部署的详情页，点击右上角的「⋯」按钮，在弹出菜单中选择 Delete，即可删除该次 Deployment。

网页端目前没有批量删除功能，只能逐个删除；如果需要批量清理，可以使用 Vercel CLI，如下：

查看 Deployment：

vercel list
 
# 输出类似
> Deployments for <account-projects>/<example.com> [472ms]
 
  Age      Project                              Deployment                                                        Status      Environment     Duration     Username
  10h      <account-projects>/<example.com>     https://<example.com>-i5a1iqk7h-<account-projects>.vercel.app     ● Ready     Production      2m           <vercel-account>
  10h      <account-projects>/<example.com>     https://<example.com>-kfqiciq3o-<account-projects>.vercel.app     ● Ready     Production      2m           <vercel-account>
  11h      <account-projects>/<example.com>     https://<example.com>-5i5a0pyzp-<account-projects>.vercel.app     ● Ready     Production      2m           <vercel-account>

删除指定 Deployment：

# 对应上面的部署地址，例如：
# https://<example.com>-i5a1iqk7h-<account-projects>.vercel.app
vercel remove <deployment-url>

一次删除多个：

vercel remove <deployment-url-1> <deployment-url-2> <deployment-url-3>

缩写：

vercel rm <deployment-url>

按 Project 清理可安全删除的 Deployment（--safe 会跳过带有活跃 Preview URL 或 Production Domain 的部署）：

vercel remove <project-name> --safe
 
# 输出类似
 
> Found 18 deployments for removal in <account-projects> [2s]
> The following 18 deployments will be permanently removed:
  dpl_45krSoRPbDq3vrYRh6LSHkWkPVFj      https://<example.com>-kfqiciq3o-<account-projects>.vercel.app      10h ago
  dpl_9wBc6RopPyASsTjWoAzytccsHAai      https://<example.com>-ckuakbjx7-<account-projects>.vercel.app      9d ago
  ...
  dpl_4nCVdhVvMspVGBVxhSkbanRJB4vg      https://<example.com>-gvkrze2ry-<account-projects>.vercel.app      450d ago
# 输入 y 确认删除
> Are you sure? (y/N) y
> Success! Removed 18 deployments [3s]
- <example.com>-kfqiciq3o-<account-projects>.vercel.app
...
- <example.com>-gvkrze2ry-<account-projects>.vercel.app

删除历史 Deployment 后：

Deployment 已删除
        ↓
实际保留的 Deployment 减少
        ↓
Deployment Storage Usage 更新

最后一步并非实时完成，社区中也有相关讨论。

目前 Vercel 会按每天的 Deployment Storage 状态更新 Dashboard，而不再沿用此前的 Billing Period Maximum，因此数值更新会更及时。

所以，刚删除 Deployment 后仍看到原来的 Usage 数值属于正常现象，等待下一次日级统计更新即可。

Retention Policy

如果不希望长期保留大量历史 Deployment，可以通过 Deployment Retention Policy 配置各类 Deployment 的保留时长，达到期限的 Deployment 会被自动删除。参见官方文档：Deployment Retention。

配置入口：控制台 Settings → Build and Deployment → Deployment Retention Policy；也可以在设置页的搜索框中输入 retention 快速定位。

各 Plan 的默认保留时长如下：

Plan	Canceled	Errored	Pre-Production	Production
Hobby	30 天	30 天	30 天	30 天
Pro / Enterprise	30 天	90 天	180 天	1 年

Team 级策略可以覆盖这些默认值，Project 级策略则只作用于当前项目，并优先于 Team 默认值。

需要注意的是，即使超过保留期限，Vercel 也不会立即删除所有 Deployment，以下情况仍会被保留：

最近创建的若干次 Deployment（Hobby 保留最近 3 次，Pro / Enterprise 保留最近 10 次）；
Ready 状态下的 Production Deployment（Hobby 保留最近 3 个，Pro / Enterprise 保留最近 20 个）；
带有 Production Alias 的 Deployment；
自定义环境（Custom Environment）分支 Alias 所指向的 Deployment；
带有任意自定义 Alias 的非 Production Deployment；
仍处于活动状态的 Git 分支上的最新 Preview Deployment（分支未被删除，且其关联的 Pull Request 未合并或关闭）。

达到保留期限后，后台任务通常会在 48 小时内将其标记为删除；如果此时仍命中上述例外，则会等到例外不再成立时重新评估，重新评估最长可能需要 30 天。

被删除的 Deployment 仍可在恢复期内从 Settings → Security → Recently Deleted 恢复；成功构建的 Deployment 恢复期为 30 天，构建失败的则可能更早被回收。

其他

如果本地源码本来就由 Git 管理，版本其实已经记录在 Git 里：提交、分支和 Tag 足以还原任意一次改动，需要回退时检出对应提交、重新部署即可。对个人项目来说这通常已经够用，不必把 Deployment Storage 当成版本库，长期堆积大量历史 Deployment（Hobby 更是只有 10 GB）。

Deployment 的优势在于切换快：每个 Deployment 都是当时已经构建好的产物，并带有独立的访问地址，Rollback 或 Promote 一步即可完成，既不需要在本地重新构建，也不依赖本地的环境和依赖版本。相比之下，基于 Git 回退需要重新构建，产物也可能因为依赖版本变化而与当时不完全一致。

两者分工不同：Git 负责记录版本，Deployment 负责提供可直接运行的快照。个人项目用 Git 记录版本通常就足够了；但这并不意味着 Deployment 没用——需要快速回滚、给别人预览，或者希望拿到与当时完全一致的产物时，Deployment 依然很有价值。