Vercel 在 2026 年 10 月 27 日宣布，當專案根目錄有一般 Dockerfile 或 Containerfile，而平台沒有偵測到其他框架時，會自動選擇 Container preset、建立映像並把流量導向該映像。過去為 Vercel 特別命名檔案或設定框架的摩擦變少，已有標準容器封裝的 HTTP 應用可以更直接試部署。

這項更新不代表 Vercel 變成傳統 VPS，也不代表任何 Docker Compose 專案都能原封不動搬上去。Container Runtime 仍是 beta，實際運行在 Vercel Functions 的執行與擴縮模型上。部署前要先判斷工作負載是 HTTP request、持續 worker、需要本機持久磁碟，還是依賴固定出口 IP，再比較 Vercel、Railway、託管容器與自架 VPS／Coolify。

這次改的是偵測與入口，不是所有限制

Vercel 的 10 月 27 日公告說明：根目錄的一般 Dockerfile 現在即可成為部署入口。如果同時偵測到 Django 等框架，框架仍優先；要強制使用容器，可執行 vercel project update --framework container，或在 vercel.json 設定 "framework": "container"。Dockerfile.vercel 與 Containerfile.vercel 仍會優先於框架偵測。

多服務專案也不是直接讀取 docker-compose.yml。官方要求在 vercel.json 的 services 中為各服務指定 root 與 entrypoint，再以 rewrites 路由。這適合前端與 API 都採 HTTP 服務的專案，但資料庫、queue、物件儲存與背景程序仍要各自找到受支援的執行位置。

先用工作負載選平台

Vercel Container Runtime 適合需要自訂系統套件、平台未自動辨識的框架，或希望用同一 Dockerfile 固定依賴的 HTTP 應用。它保留 Git push、Preview Deployment、觀測與自動擴縮的整合，團隊不必自行管理 VM、反向代理與作業系統安全更新。

Railway 類平台也以 Git 或容器快速部署為主，通常更貼近常駐服務、資料庫與多服務應用的操作模型。選擇時應用同一份需求比較區域、網路、volume、資料庫備份、健康檢查、擴縮、日誌保留、費用與事故處理，而不是只比較「能不能讀 Dockerfile」。

自架 VPS 搭配 Coolify 則提供主機層控制與較自由的服務組合，但 Coolify 是部署管理工具，不會附送 CPU、記憶體、備份或高可用。團隊要負責 VM 更新、防火牆、磁碟容量、資料庫、監控、備份還原與值班。若缺乏維運人力，表面較低的主機月費可能轉成更高的營運風險。

Google Cloud Run、AWS ECS 等託管容器可提供更完整的網路、身分與基礎設施設定，但建置、registry、load balancer、IAM 與觀測的組合通常較多。已有雲端治理能力、需要私有網路或明確資源配置時，這些選項可能比把工作負載硬塞進前端平台更合理。

Vercel Container 的邊界要逐項驗證

Container Runtime 文件指出，容器必須開啟 HTTP server；預設 port 是 80，也可由 PORT 環境變數指定。正式環境五分鐘沒有流量會 scale down，Preview 則是 30 秒；縮容時容器收到 SIGTERM，有 30 秒清理時間，之後會被強制終止。

這代表應用不能把本機記憶體當成可靠的長期 session，也不應把上傳檔案或任務狀態只留在容器檔案系統。狀態應放在外部資料庫、object storage、cache 或 queue，並讓關閉處理具有冪等性。持續取 queue 的 worker 應評估 Vercel Daemons 或其他常駐執行平台，不能只因為它也使用 Dockerfile 就當成同一種服務。

官方文件也說 custom container image 套用 Vercel Functions 的限制與 Active CPU 計費；Container Registry 另有映像與最佳化限制。截至本文查核日，Secure Compute 與 Static IP 尚未支援 custom images。需要資料庫 allowlist、第三方 API 固定出口或私有網路的專案，應先證明網路方案可行，再決定遷移。

遷移不要從 DNS 開始

第一步先盤點 Dockerfile 的 base image、CPU 架構、系統套件、build secret、port、health endpoint、啟動時間、映像大小與執行身分。移除寫死在映像中的密碼，確認 production 啟動命令會監聽平台提供的 port，並以非 root 使用者執行可行的工作負載。

第二步把狀態外移。列出本機檔案、上傳、session、排程、queue consumer 與暫存資料；為每一項指定持久服務與失敗重試規則。資料庫遷移不要綁在每個容器啟動上，避免自動擴縮時多個 instance 同時改 schema。

第三步在獨立 Preview 或測試 project 部署。若專案同時有 Next.js、Django 等可辨識框架，明確設定 Container preset，避免本機以 Docker 測試、正式卻走框架 build。測試冷啟動、並行請求、長請求、錯誤退出、SIGTERM、外部服務中斷與重新啟動。

第四步建立流量切換與回滾。先以測試網域或少量流量比較 HTTP 狀態、延遲、錯誤率、資料庫連線與日誌，再降低 DNS TTL 或使用既有 routing 漸進切換。舊平台至少保留到一個完整營運週期與備份還原演練完成，回滾條件要寫成可觀測指標，而不是臨場判斷。

成本要用實際請求模型試算

容器能部署只是技術入口，費用仍取決於 CPU 活躍時間、記憶體、流量、build、registry、觀測、資料庫與外部服務。I/O 等待與 CPU 計費方式、縮容後冷啟動、尖峰並行都會影響結果。用一週 production trace 重播到測試環境，至少比較尖峰、背景任務與低流量時段，不要只用首頁一次回應估算月費。

如果專案是無狀態 HTTP API、重視 Preview 與免維運，Vercel 新入口值得試驗；如果是常駐 worker、資料庫密集或需要固定網路，Railway、Cloud Run 或其他託管容器更可能貼合；若需要完整主機控制且團隊能承擔維運，自架 VPS／Coolify 才是合理選項。新的 Dockerfile 支援降低了搬移摩擦，但正確決策仍要回到狀態、網路、生命週期、成本與回滾證據。