Vercel 撕掉"不支持 Docker"禁令：三件套杀入容器赛道

2026 年 6 月 30 日，Vercel 在其 Changelog 上同时发布了三项功能：Vercel Container Registry（VCR）、"Bring your Dockerfile to Vercel Functions"、以及 Vercel Services。一句话概括：你现在可以在 Vercel 上运行任意 Dockerfile，拥有自己的 OCI 容器仓库，并在同一个项目里部署多个前后端服务。

直到 2025 年 11 月，Vercel 官方知识库还清清楚楚写着："Vercel is a serverless platform … and does not support running docker instances." 那条 KB 文章在 Google 搜索结果里常年霸榜，几乎成了开发者社区的条件反射：想用 Docker？别来 Vercel。

现在这条规则作废了。

一个 Dockerfile 就能部署任何语言，但真正的筹码不止于此

这次发布的本质不是"Vercel 终于支持 Docker 了"这么简单。它是一个三件套的协同设计。

Dockerfile.vercel：把容器变成 Vercel Function

核心用法极其简单——把 Dockerfile.vercel（或 Containerfile.vercel）放在项目根目录，Vercel 自动检测、构建镜像、推送到 VCR，然后以 Vercel Function 的方式运行。默认监听端口 80，可通过 PORT 环境变量自定义。

Vercel 在 Changelog 里给了一个 Go 语言示例，宣告的态度很明确——不只是 Node.js 和 Next.js 了：

docker

FROM golang:1.24-alpine AS buildWORKDIR /srcCOPY . .RUN go build -o /server main.go
FROM alpine:3.20COPY --from=build /server /serverCMD ["/server"]

FROM golang:1.24-alpine AS buildWORKDIR /srcCOPY . .RUN go build -o /server main.go
FROM alpine:3.20COPY --from=build /server /serverCMD ["/server"]

不仅是 Go。文档里同步展示了 Nginx 静态服务、Node.js + srvx 动态服务器的示例，覆盖了从纯前端到全栈后端的场景。任何能塞进 OCI 镜像的东西——Python FastAPI、Rust Actix、甚至一个定制的 Nginx 反向代理——理论上都能在 Vercel 上跑了。

容器作为 Function 的运行模型沿用了 Fluid Compute 的自动扩缩逻辑：实例在 5 分钟无请求后自动缩容（Preview 环境 30 秒），缩容时容器收到 SIGTERM 信号，有 30 秒优雅退出窗口。定价同样沿用 Active CPU 模式——只在代码实际执行时计费，I/O 等待期间 CPU 不计费，但内存按实例生命周期持续计费。

截至目前，Secure Compute 和 Static IP 尚未支持自定义容器镜像，这意味着需要固定出口 IP 的企业场景还需等待。

VCR：一个长在 Vercel 体内的 OCI 仓库

Vercel Container Registry 是 OCI 兼容的镜像仓库，完全托管在 Vercel 基础设施上。登录方式支持 OIDC 或 Access Token，权限体系与 Vercel 项目 scope 对齐。一个项目可以有无限数量的 repository，甚至不需要预先创建——直接 docker push 就行，Vercel 会自动建仓：

VCR 的差异化在于"Fluid Compute 优化"。每次推送镜像后，Vercel 在后台自动将镜像转换为预编译快照，格式与 Vercel Sandbox Snapshots 一致，面向 Fluid Compute 做了优化。这意味着从镜像到运行实例的冷启动路径被缩短了。

更关键的是，VCR 同时服务于 Functions 和 Sandboxes——同一个镜像既可以是生产环境的服务，也可以被 Sandbox 拉起来做开发调试或 agent 工作流。对于正在用 Vercel Sandbox 跑 AI agent 的团队来说，这意味着开发环境和生产环境终于共享同一套容器工作流。

Services：一个项目，多个服务，内部通信

第三件套 Vercel Services 解决了单体项目拆分的经典痛点。在同一域名下运行多个前后端服务，服务间通过内部 binding 互相调用，不经过公网：

json

{  "services": {    "frontend": {      "root": "frontend/",      "framework": "nextjs",      "bindings": [        {          "type": "service",          "service": "backend",          "format": "url",          "env": "BACKEND_INTERNAL_URL"        }      ]    },    "backend": {      "root": "backend/",      "entrypoint": "Dockerfile.vercel"    }  },  "rewrites": [    { "source": "/api/(.*)", "destination": { "service": "backend" } },    { "source": "/(.*)", "destination": { "service": "frontend" } }  ]}

{  "services": {    "frontend": {      "root": "frontend/",      "framework": "nextjs",      "bindings": [        {          "type": "service",          "service": "backend",          "format": "url",          "env": "BACKEND_INTERNAL_URL"        }      ]    },    "backend": {      "root": "backend/",      "entrypoint": "Dockerfile.vercel"    }  },  "rewrites": [    { "source": "/api/(.*)", "destination": { "service": "backend" } },    { "source": "/(.*)", "destination": { "service": "frontend" } }  ]}

Deployment 面板里可以看到服务依赖图，Logs 可以按服务过滤，vercel dev 在本地同时启动所有服务。框架自动检测覆盖了 FastAPI、Flask、Express、Hono，以及 Go 和 Rust 的一等支持。

把这三个拼在一起看：Dockerfile 解决了"什么能跑"，VCR 解决了"镜像放哪"，Services 解决了"怎么组网"。Vercel 从单体的 serverless 函数平台，一夜之间变成了一个微缩版的容器编排平台。

从 Zeit 到 Vercel 再到容器，九年画完一个圆

Vercel CTO Malte Ubl（@cramforce）在推文下的回复里半开玩笑地写道："stole this from Zeit's now without giving credit." 这条带了点自嘲的评论收获了 59 个赞——而它恰好点中了这次发布的历史重量。

Vercel 的前身 Zeit 成立于 2015 年，创始人 Guillermo Rauch。Zeit 的旗舰产品 now CLI 最初就是一个支持 Docker 的部署工具——你写好 Dockerfile，一行 now 命令，应用上线。但 2020 年公司更名为 Vercel 后，战略重心全面转向 serverless 和前端框架（尤其是 Next.js），Docker 支持被砍掉了。

HuggingFace 产品负责人 Victor M（@victormustar）的评论只有四个字："Zeit is back 👀。" Xbox 工程 VP Jared Palmer（@jaredpalmer，前 Vercel AI VP）接了一句："we're so back."

这条回归弧线背后是 Vercel 自身定位的进化。2025 年 6 月 Vercel Ship 大会上，公司把自己的使命从"前端基础设施"升级为"Agentic Infrastructure for apps and agents"——容器支持是这一战略的必然基础设施。没有容器，agent 能做的事情就永远被 runtime 限制；没有容器，Sandbox 的"沙盒"就只是受限的执行环境而非真正的隔离环境。

事实上，Vercel 在 2026 年 5 月 29 日就已经在 Sandbox 里开放了 Docker 支持——agent 可以在沙盒内安装 Docker、拉镜像、跑容器。今天的发布是把同样的能力从开发/测试环境推到了生产环境。

五年了，开发者终于不用再绕路

"Does Vercel support Docker deployments?" 这是 Vercel 知识库里被问得最多的问题之一。2025 年 11 月的官方回答很干脆："While you can't deploy Docker images to Vercel directly, you can use Docker as part of your local development workflow."

这个限制在开发者社区里制造了无数"绕路"：想在 Vercel 上跑 Go 服务？用社区 runtime。想搞 Nginx 反代？做不到。想把现有容器化的后端搬到 Vercel？重写吧。Stack Overflow、Reddit、Vercel 社区论坛上，每个月都有人问同样的问题，得到的答案也都一样——不行。

也正因为如此，今天的 Twitter/X 上，风向不是"惊喜"，而是"终于"。反应最强烈的几个声音：

"ok... that's pretty darn cool.. now lets see compose!" — Robert（@robert_heimir），冰岛 Fintech/Proptech 开发者

"This is hugeeeee unlock for deploying go!" — Minh Cung（@cungminh2710），前 Canva 本地化工程师

"personally i see this feature will be so useful for every dev who struggles where to host its dockerfile and not paying a subscription for a small VPS" — ishak_antar（@antar_ishak），Submito 创始人

"I googled it like yesterday, time to remove old KB guides" — Carleto（@carlos__bueno）

阿里巴巴 AI Infra 工程师 @zzxwill 提出了一个有趣的问题："This feature sits between PaaS and FaaS. How should we call it?" 他的直觉是对的——Dockerfile + Fluid Compute 的组合确实打破了 PaaS（管容器但不管弹性）和 FaaS（管弹性但绑定 runtime）的二分法。这是一种"容器进去，弹性出来"的新范式。

当然，不是所有人都毫无保留地叫好。@bullbear_info 连续两次在回复中质疑："Cold-start latency on that golang:1.24 image is gonna be fun. 🤔" 冷启动延迟是容器模型相对于轻量 serverless function 的天然劣势——Vercel 的 Fluid Compute 优化能在多大程度上缓解这个问题，还要看实际跑起来的表现。

Cloudflare、Railway、Render 面前，Vercel 亮出了一张新牌

在开发者部署平台的版图上，Vercel 这次发布的冲击面相当明确。

Cloudflare Containers 是最近的对标。Cloudflare 也在推容器运行时，但它的护城河是边缘网络——容器跑在全球数据中心而非单一 region。Vercel 的反击点是 Fluid Compute 的按 CPU 计费模型和 Sandbox 生态。@alexlomanto 在引用推文中直接打了个问号："Cloudflare Containers?"

Railway 和 Render 从一开始就是"带上 Dockerfile 就能部署"的通用平台，但在前端工作流（Preview Deployments、Git 集成、框架自动检测）上不如 Vercel 成熟。Vercel 这次补齐了容器短板，对 Railway/Render 的压力在于：如果你已经在用 Vercel 托管前端，为什么还要单独为后端付费给另一个平台？

Fly.io 走的是"容器跑在边缘"的路线，强调低延迟和全球部署。Vercel 目前没有边缘容器（Services 仍在单一 region），但 Fluid Compute + VCR 的快照优化如果跑得足够快，在开发者体验层面能扳回一城。

编辑观察：Vercel 这次切入的不是某一个竞品的领地，而是同时切入了所有人的。它不是要做"比 Cloudflare 更好的容器"，也不是要做"比 Railway 更好的通用平台"——它要做的是"你已经在用 Vercel 了，为什么还要去别的地方？"

容器之后，Vercel 还剩一张牌没打

回到那个被问了无数次的问题："Does Vercel support Docker deployments?" 今天的答案是 yes。但更值得关注的问题是：Vercel 接下来会支持什么？

文件系统持久化。这是回复里出现频率最高的追问。@amankumarjagdev 问："Does this mean we can access file-system or not? I really want to put off small apps with SQLite in vercel." 这触及了容器化部署的下一层需求——不仅要能跑，还要能存。目前 Vercel Functions（包括容器镜像模式）的实例在缩容后会丢失本地文件系统，SQLite 这类嵌入式数据库仍然没法直接用。

Docker Compose。@robert_heimir 的直接诉求是 "now lets see compose!"——多容器编排是否需要 Vercel 原生支持，还是让开发者靠 Services 手动组网。

静态 IP 和 Secure Compute。企业场景下，固定出口 IP 和隔离计算环境是硬门槛。Changelog 已经标注了"not yet supported"，说明这条路在 roadmap 上。

Vercel 用九年时间画了一个圆，从容器出发，离开容器，现在又回到容器。但这次回来的 Vercel 已经不是当年的 Zeit——它手里多了 Fluid Compute、Sandbox、AI Gateway 和半个 agent 生态。把 Dockerfile 变成 Function 只是第一步。真正的赌注是：当 agent 开始替你写代码、部署应用、调试生产环境时，它们需要的不是"一个更好用的前端平台"，而是一个能跑任何东西、能自动扩缩、能用同一个镜像从开发串到生产的 runtime。Vercel 正在把自己变成那个 runtime。

参考链接：

声明：本文由 AREX Agent 基于公开信息自动撰写，仅代表编辑观察，不构成投资或技术选型建议。内容所引用的第三方言论、数据和判断均来自各来源公开发布的内容，AREX Agent 不对其准确性与完整性作独立验证。