多站點託管
讓 200+ 個網站共用一套部署、憑證與回滾流程
我們把原本分散的網站上線工作，整理成可驗證、自動部署並保留版本的多站點託管平台。
問題
網站數量持續增加時，逐站上傳檔案、設定網域與處理憑證，不只耗時，也很難知道每個站點目前跑的是哪一版。任何一次手動覆蓋都可能讓回復變得困難；新網站上線與舊網站更新需要一套共同、可追蹤的流程。
限制
- 平台必須同時容納大量獨立網域與靜態網站，又不能為每個網站長期維護一套容器。
- 既有網站仍要持續服務，網域與憑證遷移不能依賴難以重現的人工步驟。
- 客戶識別、站點流量、成本與內部營運資料不得公開。
我們做了什麼
共用執行層，網站檔案獨立保存
以 Cloud Run 上的 Nginx 作為共用入口，網站封包與版本放在 Google Cloud Storage，讓運算層能獨立擴縮。
沒有選擇另一條路，因為 沒有為每個網站建立一個常駐容器，因為那會把映像、部署與維運數量一起放大。
把部署做成可驗證的流程
上傳後先檢查封包結構，再解壓、建立版本並切換服務版本；失敗會停在切換前。
沒有選擇另一條路，因為 沒有讓人直接覆蓋線上檔案，因為部分寫入或錯誤封包會留下難以復原的狀態。
自動處理網域與 TLS
將 Cloudflare DNS、SSL 與站點設定納入同一條建置流程，並以 DNS-01 驗證降低切換時對現有服務的干擾。
沒有選擇另一條路，因為 沒有把憑證簽發留作逐站人工操作，因為大量站點下容易遺漏、過期，也難以稽核。
保留版本，而不是只留最新檔案
每次部署產生獨立版本，站點指向可回切，讓錯誤版本不必靠重新上傳才能復原。
沒有選擇另一條路，因為 沒有只保存最後一次上傳，因為那會讓回滾依賴備份是否剛好存在。
成果
- 200+ 個網站由同一套平台集中管理。
- 網站封包從上傳、驗證到部署形成一致的自動化流程。
- 每次部署保留版本，遇到問題時可以切回先前版本。
技術
- Google Cloud Run
- Nginx
- Google Cloud Storage
- Cloudflare
回頭看
如果重來，我們會更早把失敗狀態、操作稽核與租戶邊界做成平台的一級概念。站點少的時候，它們像是管理功能；站點跨過一定數量後，它們其實就是核心架構。