Vercel容器镜像仓库单层上限升至2GB，总量15GB不变

Vercel Container Registry 迎来一项关键更新：单个压缩镜像层的上限从 500 MB 提升到 2 GB，而镜像总量上限保持 15 GB 不变。这意味着开发者可以把更大的依赖包、模型文件或运行时组件塞进同一层，减少因分层过细带来的管理成本和推送次数。

分层上限翻四倍，不改总容量

这次调整的核心是单层压缩大小上限。此前的 500 MB 对不少现代工作负载来说偏紧——大型 Node.js 依赖树、包含原生扩展的 Python 环境、甚至一些预训练模型权重，都容易在单层上触顶。提升到 2 GB 后，常见的中大型镜像可以更自然地组织分层。

镜像总量上限仍为 15 GB。这说明 Vercel 的定位不是做超大镜像仓库，而是让标准 Web 应用和服务端工作负载在合理体积内获得更宽松的分层自由度。对于需要更大体积的场景，仍需在构建阶段做裁剪或拆分。

关于容器镜像层与压缩层

容器镜像由一系列只读层叠加而成，每一层对应 Dockerfile 中的一条指令（如 RUN、COPY）。镜像拉取时各层可并行下载并复用缓存，因此分层策略直接影响构建与分发效率。文中的“压缩镜像层”指经过 gzip/zstd 压缩后上传到 Registry 的层体积，与解压后的磁盘占用并不相同——一个 2 GB 的压缩层解压后可能显著更大。这正是单层上限与总量上限需要分别考量的原因：Registry 侧按压缩后体积计量存储与传输，而运行时要按解压后体积占用磁盘。

兼容标准 Docker 工作流

Vercel Container Registry 没有另起炉灶，而是直接兼容 docker push、docker pull、docker tag 等标准命令。推送镜像时会自动创建仓库，省去手动初始化的步骤。典型用法是通过 buildx 直接构建并推送：

docker buildx build --push -t vcr.vercel.com/team/project/repository:tag

这种设计降低了迁移成本。已经在用 Docker 的团队不需要学习新的镜像格式或认证流程，把 registry 地址指向 Vercel 即可。

关于 buildx 与 OCI 镜像规范

docker buildx 是 Docker 的构建前端，基于 BuildKit 引擎，支持多平台构建、并行构建和更灵活的缓存导出。它推送镜像时遵循 OCI Distribution 规范，因此任何兼容该规范的 Registry 都能接收 docker push 的产物。Vercel Container Registry 正是实现了这一规范的服务端，这也是它能直接承接标准 Docker 命令、无需专用客户端的原因。理解这一点有助于判断迁移成本：只要工具链输出的是标准 OCI 镜像，切换 Registry 地址即可，无需改动镜像格式。

仓库共享与公开访问

仓库可以设为公开，供任意 Vercel 团队只读拉取，也可以定向共享给特定团队，数量上限为 100 个。操作入口有两个：仪表盘或 vercel vcr permissions 命令。

值得关注的是，Vercel Sandbox 运行所依赖的 Vercel Managed Images 正是通过普通公开仓库分发的，构建方式与任何团队可用的公开仓库功能一致。这相当于官方用自己的产品来承载核心镜像分发，间接验证了该功能的可用性。

CLI 与 CI 集成

仓库、镜像和标签的管理通过 Vercel CLI v58.3.0 及以上版本的 vercel vcr 命令完成。CI 场景下，GitHub Actions 可以通过 vercel/vcr-action/login 动作结合 GitHub OIDC 登录，无需在仓库中长期保存 registry 凭证。这一点对安全实践偏保守的团队比较友好，减少了密钥轮换和泄露风险。

镜像推送后会进行后台优化，如果优化失败，仪表盘会显示错误状态，重新推送同一镜像即可触发重试。这种异步处理方式让推送流程不必等待优化完成，但也要求团队在发布流程中留意状态反馈。

关于 GitHub OIDC 免密登录

传统 CI 推送镜像需要在仓库 Secrets 中长期保存 Registry 账号密码或 Token，一旦泄露影响面大，且需要定期轮换。GitHub OIDC 方案改为由 GitHub 在每次工作流运行时签发一个短期、可验证的身份令牌，Registry 侧通过校验该令牌的签发方与仓库声明来授权，从而避免长期凭证落地。这一机制依赖 Registry 端支持 OIDC 信任配置，也要求工作流声明 id-token: write 权限。对于多仓库、多环境的团队，它把凭证管理从“分发密钥”变成“配置信任关系”，显著降低运维负担。

对开发者的实际影响

单层上限提升最直接的价值是简化镜像结构。过去为了绕开 500 MB 限制，团队可能被迫拆分依赖层、压缩资源或引入额外的构建步骤；现在这些妥协可以适度减少。不过 15 GB 的总量红线仍在，镜像体积管理依然是必要功课，尤其是在分层缓存和拉取效率上。

结合标准 Docker 兼容、团队共享和 OIDC 登录来看，Vercel 正在把容器镜像仓库做成其部署链路里的基础设施组件，而不是独立产品。对于已经在 Vercel 上托管应用的团队，把镜像仓库一并纳入同一平台，能减少跨平台配置和凭证管理的工作量。