撐了 5 年後，Vercel 收編 Dockerfile｜Rails、Spring Boot、FastAPI 一鍵上 Fluid 算力
一句話總結
Vercel 6 月 30 日上線 Dockerfile.vercel，Rails、Spring Boot、FastAPI 等傳統 web 框架一次 git push 就能跑在 Fluid compute 上，按實際 CPU 用量計費。
撐了 5 年後，Vercel 收編 Dockerfile｜Rails、Spring Boot、FastAPI 一鍵上 Fluid 算力
Vercel 6 月 30 日在 Changelog 上線 「Bring your Dockerfile to Vercel Functions」：專案根目錄放一份 Dockerfile.vercel 或 Containerfile.vercel，容器監聽 $PORT，`git push` 之後 OCI 鏡像自動 build、推到 Vercel 內建的 Container Registry，跑在 Fluid compute 上並按 實際 CPU 用量計費 — 閒置時不掏錢。
這是 Vercel 五年來對 Docker 態度的一次徹底翻轉。過去這家公司的姿態是「serverless functions 是唯一入口，你的 backend 得改成無狀態函數才配進門」，Rails、Spring Boot、Laravel、ASP.NET 這種需要常駐進程或原生依賴的應用一律被擋在 Fly.io、Railway、Render 那條 Docker PaaS 賽道那頭，需要 hyperscaler 的則往 AWS App Runner 或 Google Cloud Run 遷。這次官方博客的自白很直接：「the idea was right, but the infrastructure to make it great didn't exist yet」— 承認前五年的 serverless-only 路線抓不住所有場景。
支援列表寫得攤開：Rails、Spring Boot、Express、Laravel、ASP.NET、FastAPI，加上任何跑在 nginx 後面的 HTTP 服務。門檻只剩一句話「speaks HTTP, it deploys」。Vercel 的原話：「Two files, and you are live. Every `git push` rebuilds the image and hands you a fresh preview URL.」預覽環境、日誌、路由、自動擴縮全部沿用 Functions 那套。
Fluid compute 的計費模型是這場收編真正的殺手鐧。Fly.io 按 VM 全時計費，Railway 是按分鐘算 CPU + RAM，Vercel 這次直接搬 Functions 的 active CPU 模式 — 你的容器在 await 資料庫的時候不計費。對很多長尾流量的 SaaS 後端，同樣 QPS 下電費比 Fly / Railway 便宜一大截。
賭贏，Rails / Spring 這一整批傳統 web 框架跟著 Next.js 一起被 Vercel 收編，Vercel 從「Next.js 的雲」升格成「所有 web app 的雲」，Fly.io 4 億美元估值和 Railway 的 Series B 敘事同時被削一層。賭輸，Container Registry 的存儲費、跨區冷啟動、Fluid 的併發上限這些細節撞到 Docker 用戶的真實工作負載，五年信任缺口不是兩個 config file 能補回來的。
via Vercel Changelog / Vercel Blog / Vercel Docs / Vercel KB
Vercel 6 月 30 日在 Changelog 上線 「Bring your Dockerfile to Vercel Functions」：專案根目錄放一份 Dockerfile.vercel 或 Containerfile.vercel，容器監聽 $PORT，`git push` 之後 OCI 鏡像自動 build、推到 Vercel 內建的 Container Registry，跑在 Fluid compute 上並按 實際 CPU 用量計費 — 閒置時不掏錢。
這是 Vercel 五年來對 Docker 態度的一次徹底翻轉。過去這家公司的姿態是「serverless functions 是唯一入口，你的 backend 得改成無狀態函數才配進門」，Rails、Spring Boot、Laravel、ASP.NET 這種需要常駐進程或原生依賴的應用一律被擋在 Fly.io、Railway、Render 那條 Docker PaaS 賽道那頭，需要 hyperscaler 的則往 AWS App Runner 或 Google Cloud Run 遷。這次官方博客的自白很直接：「the idea was right, but the infrastructure to make it great didn't exist yet」— 承認前五年的 serverless-only 路線抓不住所有場景。
支援列表寫得攤開：Rails、Spring Boot、Express、Laravel、ASP.NET、FastAPI，加上任何跑在 nginx 後面的 HTTP 服務。門檻只剩一句話「speaks HTTP, it deploys」。Vercel 的原話：「Two files, and you are live. Every `git push` rebuilds the image and hands you a fresh preview URL.」預覽環境、日誌、路由、自動擴縮全部沿用 Functions 那套。
Fluid compute 的計費模型是這場收編真正的殺手鐧。Fly.io 按 VM 全時計費，Railway 是按分鐘算 CPU + RAM，Vercel 這次直接搬 Functions 的 active CPU 模式 — 你的容器在 await 資料庫的時候不計費。對很多長尾流量的 SaaS 後端，同樣 QPS 下電費比 Fly / Railway 便宜一大截。
賭贏，Rails / Spring 這一整批傳統 web 框架跟著 Next.js 一起被 Vercel 收編，Vercel 從「Next.js 的雲」升格成「所有 web app 的雲」，Fly.io 4 億美元估值和 Railway 的 Series B 敘事同時被削一層。賭輸，Container Registry 的存儲費、跨區冷啟動、Fluid 的併發上限這些細節撞到 Docker 用戶的真實工作負載，五年信任缺口不是兩個 config file 能補回來的。
via Vercel Changelog / Vercel Blog / Vercel Docs / Vercel KB
