自架 PaaS 這條路走了三四年，工具堆疊從 CapRover 起頭、Dokploy 補齊 Docker Compose、Pangolin 補齊反向穿透，但沒有一個真的把「AI 代理直接接手基礎設施」變成產品功能。Coolify v4 在 2026 年 5 月的正式版把 MCP server 塞進 PaaS 主體，是第一個帶原生 MCP 支援的自架 PaaS——Claude Code、Cursor 以及自寫的 AI 代理可以透過標準協定登入 Coolify 實例、查詢容器狀態、抓部署歷史。
MCP 不是 v4 唯一的亮點，甚至不是最重要的一項。這個版本從 v3 是破壞性改版：資料庫結構重寫、遷移不是就地升級、多伺服器編排從實驗性變成一級公民、one-click template 從 200 多支翻到 280 支、Ollama 拿到專屬部署路徑。真要從 v3 升上來、或者第一次在臺灣機房 VPS 上部署自架 PaaS 的團隊，值得先把這幾個點的細節看清楚，再決定要不要跳。
MCP server 在自架 PaaS 上到底能拿到什麼
Coolify v4.1 加入的 MCP server 是實例層級的功能，預設關閉，需要在 UI 或 API 端明確開啟。開起來之後 Coolify 會在同一個 process 內暴露 MCP 端點，接受 stdio 或 SSE 兩種傳輸方式。目前釋出的第一版工具集是唯讀的——列出應用程式、查看部署歷史、抓 log、確認 SSL 憑證狀態這類查詢動作可以直接跑，但真正會改變 stack 狀態的動作（重啟服務、觸發部署、換環境變數）留在後續版本才會開放。
這個設計選擇看起來保守，但實務上是對的。MCP 的權限模型還在演化，AI 代理接受長輸入之後被 prompt injection 誤導的案例過去半年已經發生過好幾起——如果第一版就把「刪掉整臺 VPS 的容器」放進工具集，出事的機率不是零。先把讀取權限跑穩、再逐步開放寫入，是合理的產品節奏。
實際用起來的樣子是這樣：在 Claude Code 或 Cursor 裡把 Coolify 的 MCP endpoint 跟 API token 設定進去，代理就能回答「這臺 VPS 上哪個服務昨天部署失敗？」「這支應用最近一次 push 之後 log 有沒有 error？」「TLS 憑證什麼時候要到期？」這類問題，不用再登進 Coolify UI 一頁一頁翻。維運工程的體感差異是把「先確認狀態、再決定動作」這個回路的前半段壓縮到近乎零成本。
值得留意的是安全邊界。MCP 端點掛在 Coolify 主 process 上，跟原本的 UI/API 共用同一個網路面，想從公網對外開放要多做一層保護——放在 Cloudflare Access 或 Pangolin 的 tunnel 後面、限制 API token 的權限範圍、以及在 audit log 裡確認 AI 代理的操作有被記錄下來，都是進生產前該有的動作。
v3 遷到 v4 是重裝，不是升級
Coolify 在 release note 裡把「不能就地升級」寫得算清楚，但實際遷過的人會知道這句話背後的工作量比想像的大。v4 的資料庫 schema 幾乎重寫，multi-tenant、team 權限、audit log 這三塊都改了資料結構。官方給的建議路徑：先把 v3 的資料匯出成 JSON、開一臺新 VPS 裝 v4、再把 JSON 匯入，中間需要人工對照確認哪些欄位需要調整。
實務上會踩到的坑集中在三個地方。第一是 GitHub App 連線——v3 的授權要在 v4 重新建立，因為 webhook 端點路徑跟簽章方式都改了。舊 App 可以留著，但正在跑 auto-deploy 的服務會在切換窗口內收不到新 commit 的通知，這段時間要事先安排靜默或用手動觸發補上。
第二是環境變數的處理方式。v3 把環境變數存成明文字串，v4 加了加密儲存跟共用群組概念，匯入時如果變數值含有 $ 或 {{ 這類跳脫字元，會被 v4 的樣板引擎誤解。匯入前把值先 base64 一次、匯入後再解回來是最省事的做法。
第三是 Traefik 反代組態。v3 的 Traefik label 直接寫死在容器 metadata 裡，v4 改成透過 middleware 檔案動態產生，等於原本客製化過的 Traefik 規則要重新對照 v4 的 middleware 語法寫一次。改動不多，但需要一份一份看。
給還在 v3 的環境的建議：如果目前沒有明確痛點、v3 也還在收 security patch，可以再等一兩個月觀察 v4.x 的穩定度；如果原本就在規劃遷去多伺服器架構、或者想試 MCP，那 v4 就是必經之路。留一週準備時間、一個週末的切換窗口，通常夠。
一次 280 個 one-click template，Ollama 進了第一線
Template 數量翻倍看起來像行銷數字，但實際比較 v3 跟 v4 的清單，會看到取向的轉變：v3 多的是資料庫、CMS、監控這類傳統自架服務；v4 補進來的 80 支裡有相當比例是 AI 相關——Ollama、Open WebUI、LibreChat、Jan、Fabric 這些過去要自己寫 compose 檔的東西，現在都是一鍵起容器。
Ollama 特別被列為 first-class，意思是 Coolify 幫它做了幾件額外的事：預設把 GPU passthrough 的 flag 開好、模型儲存資料夾用 named volume 而不是 bind mount（避免權限踩坑）、以及跟 Open WebUI 做了 template 綁定——選 Open WebUI 部署會自動帶起可用的 Ollama backend。對想在 VPS 上跑本地 LLM 推論的團隊，這個組合把「從 zero 到 chat interface」的時間壓到十分鐘內。
跟 Dokploy 的 template 生態比，Coolify 的一鍵服務數量領先、但同一支服務常常沒有多個 flavor 可選（例如 PostgreSQL 只給一個版本組合）。Dokploy 的 template 少、但可組合性強，每個服務留給使用者更多客製空間。取向不同，適合的團隊也不同。
多伺服器編排從加購走進預設
v3 時代的多伺服器管理是專業版才有的付費功能，v4 把整套邏輯搬到開源核心，任何自架實例都能加 remote server。技術底層走的是 SSH agent + Docker Swarm——中央 Coolify 實例透過 SSH 部署到遠端節點、以 Swarm 的 overlay network 做 service discovery。
實務上這意味著跨區域部署變得可行。中央控制臺放在臺灣機房、edge 節點放在需要就近服務的地方，兩邊只要有 SSH 連通就能納管。Coolify 對 remote server 加了 exponential backoff——連不上的節點不會被反覆重試把主 process 拖慢，而是逐步拉長重試間隔，這對跨國 latency 較高的鏈路特別有意義。
需要小心的是安全模型：SSH key 從中央 Coolify 對外連遠端 root，等於中央實例被打就等於所有節點被打。實務建議是每個 remote server 用獨立的 SSH key、key 不重用、限制 SSH 只能從中央 Coolify 的固定 IP 進來。另一個做法是在遠端節點上跑 non-root Coolify agent，只給它 Docker socket 存取權——這個做法在 v4.1 有實驗性支援。
選 Traefik 還是 Caddy 當反代
Coolify v4 預設反代仍然是 Traefik，但支援切成 Caddy。這個選擇對長期維運影響不小。
Traefik 的優勢是動態組態處理最完整——服務新增、刪除、健康檢查都能即時反映到路由規則，middleware 生態成熟。缺點是設定複雜度高、log 格式冗長、遇到憑證問題除錯需要翻文件。
Caddy 的優勢是設定極簡、自動 HTTPS 一直是招牌、log 直接易讀。Coolify 對 Caddy 的整合在 v4.1 才算真的完整——之前版本切成 Caddy 會遇到 WebSocket 支援不完全的問題。純 HTTP/HTTPS 的服務、又不需要複雜 middleware 規則的環境，Caddy 是更輕的選擇。
部署裡有大量需要 rate limiting、複雜 rewrite、TCP/UDP proxy 這類需求，繼續用 Traefik；只是把幾個 web app 對外開，換成 Caddy 通常會讓維運變輕鬆。混用不建議——同一臺 Coolify 實例上兩套反代同時跑會有 port 衝突。
什麼樣的環境該現在跳、什麼樣的該再等
單臺 VPS 上跑三五個容器、又沒有 AI 代理接手部署需求的環境，v3 還能繼續跑一段時間。v3 分支還在收 security patch 的階段，有夠的時間觀察 v4 的穩定度。
真正該優先評估遷移的是三種情境。第一種是打算橫向擴充節點的環境——v4 的多伺服器編排是免費的能力，v3 沒有替代路徑。第二種是要跑本地 LLM 推論的團隊——Ollama first-class template 加上 GPU passthrough 預設好，比手動寫 compose 省下大量時間。第三種是想用 AI 代理管基礎設施的——MCP server 是 v4 獨有，不會 backport 到 v3。
自架 PaaS 這個類別在 2026 走到比較成熟的階段：Coolify 走 AI 整合路線、Dokploy 專注 Docker Compose 純粹體驗、CapRover 停在單機穩定路線。三個工具服務的族群不再重疊，選擇比過去更清楚。
臺灣機房 VPS 想搭配 Coolify v4 跑生產環境，網路品質跟 CPU 效能是兩個實際影響體感的變數——Traefik 的 hot reload、Ollama 的推論都在吃 CPU；跨區部署的 remote server 對 latency 敏感。NCSE Network 在是方電訊機房提供 Intel Gold CPU、NVMe SSD 規格的 VPS，網路走臺灣直連 IP Transit，適合作為 Coolify 中央實例或跨區 edge 節點的落腳點；需要評估自架 PaaS 部署路徑的團隊可以到 ncse.tw 看目前的規格與價格。
