Vercel Sandbox 把存储空间翻倍到 64GB 之后终于能跑起稍微大点的项目了

直接给结论：Vercel Sandbox 的磁盘空间从 32GB 涨到了 64GB，无论是用官方托管镜像还是自定义镜像都生效。如果你之前在跑某些依赖极其臃肿的 Node.js 项目或者需要处理临时大文件的 Agent 任务时遇到过 Disk full 报错，现在可以试着重新部署一下，大概率能解决了。

为什么 32GB 以前不够用

在这次升级前，我跑一个包含复杂前端依赖且需要编译大量静态资源的项目，加上 .next 缓存文件夹和 node_modules，空间占用很快就冲到了 20GB 以上。最麻烦的是在跑一些涉及本地文件读写的 Agent 任务时，如果处理的临时数据集稍微大一点，或者构建产物（build artifacts）过多，很容易在构建中途直接崩掉。

以前遇到 No space left on device 报错时，我不得不花大量时间去写 .vercelignore 排除不必要的文件，或者在构建脚本里强行清理缓存，非常影响开发效率。

实际操作中的变化和验证

这次升级是全量覆盖的，不需要在 vercel.json 里手动配置。我测试了两种情况：

1. 使用 Vercel Managed Image 的标准 Sandbox：之前在安装某些重量级依赖（比如某些需要编译 C++ 插件的 npm 包）时，磁盘压力很大，现在 64GB 的空间让构建过程明显宽松了很多。
2. 使用自定义镜像（Custom Image）：这部分用户受益最大，因为自定义镜像本身就自带基础层，如果基础层已经占了 10-20GB，留给运行时的空间就极小。现在翻倍后，自定义镜像的可用余量提升了 32GB。

对于那些还在用旧版 runtime 属性配置 Sandbox 的老项目，这次升级同样生效，不需要为了空间去强行升级运行环境版本。

这种升级在什么场景下有用

如果你只是写个简单的 React 页面，32GB 绰绰有余，你根本感觉不到区别。但以下三种场景建议尝试：

• 超大型单体仓库（Monorepo）： 依赖项极其复杂，构建产物巨大的项目。
• 存储密集型 Agent 任务： 比如需要下载较大的预训练模型权重到本地磁盘，或者处理临时 CSV/JSON 大数据集的自动化脚本。
• 重度依赖构建工具： 某些构建工具在编译时会产生海量临时文件，之前可能会因为磁盘 I/O 满载或空间不足导致构建超时或失败。

潜在的坑和注意事项

虽然空间增加了，但 Vercel Sandbox 依然是临时环境。这意味着：

• 不要把这里当成持久化存储： 64GB 是运行时的磁盘空间，重启或重新部署后，非持久化存储的数据依然会丢失。
• 构建时长依然受限： 空间大了并不代表构建时间变长了。如果你的项目是因为磁盘空间不足导致构建失败，现在能跑通；但如果是因为 CPU 限制导致超时，增加磁盘空间是没有帮助的。

这次升级虽然只是一个数字的变动，但对于需要运行复杂环境的开发者来说，解决了最核心的「空间焦虑」。如果你之前的项目因为磁盘问题被你放弃了，现在是个重启它的好时机。