觀點 · 資訊分享

Cloudflare 推出 Worker Previews:每個 Git 分支一個獨立預覽環境,測試不再碰到正式資料

Cloudflare 讓 Workers 的每個 Git 分支都有自己的預覽環境:獨立的網址、設定、密鑰與 Durable Objects 狀態,正式環境完全不受影響。還能掛在自己的網域、用 Cloudflare Access 鎖起來。

發布
2026-09-22
篇幅
約 4 分鐘 · 1,942 字
結構
7 節 + 3 題常見問題
標籤
#Cloudflare#Workers#預覽環境#CI/CD
Cloudflare 推出 Worker Previews:每個 Git 分支一個獨立預覽環境,測試不再碰到正式資料

一句話看懂:Cloudflare Workers 現在可以替每個 Git 分支自動建立一個獨立的預覽環境,設定、密鑰和資料狀態都跟正式環境分開,測試再也不怕改壞線上資料。

Cloudflare Worker Previews 上線資訊圖卡:每個 Git 分支一個跟正式環境一樣、但完全隔離的預覽站

先用白話講:預覽環境是什麼?

想像你要重新裝潢一家正在營業的餐廳。如果直接在店裡敲敲打打,客人一定受影響;比較好的做法是先在隔壁搭一間「樣品屋」,裝潢好、試住沒問題,再把同樣的設計搬進正式店面。

軟體開發的 預覽環境(Preview) 就是這間樣品屋。工程師每改一個功能,就開一個 Git 分支,再替它搭一間跟正式環境幾乎一樣、但完全隔離的測試站。

問題是,以前很多團隊只有一間共用的「測試站(staging)」,大家搶著用,而且測試站跟正式站的設定常常不一樣,導致「測試站正常、上線就壞」。

發生什麼事

Cloudflare 在 9 月 22 日推出 Worker Previews:

  • 每個 Git 分支一個環境:有自己的程式碼、設定、網址、可觀測性與狀態
  • 一行指令建立:執行 npx wrangler preview;如果 Worker 已經用 Workers Builds 連接 Git,推送分支就會自動建立
  • 固定網址:同一個分支每次推送,都會更新同一個預覽網址
  • 可以同時跑數百個預覽,彼此互不影響,也不影響正式環境
  • 狀態隔離:每個預覽會自動建立新的 Durable Objects 命名空間與 Containers 應用
  • 可觀測性:每個預覽都有自己的紀錄、錯誤、指標與追蹤資料
  • 自訂網域與存取控制:預覽網址可以掛在自己的網域下,並用 Cloudflare Access 要求登入

跟以前的預覽網址差在哪?

類別 以前的 Version URL Worker Previews
對應的對象 某個上傳過的版本 一個 Git 分支
使用的資源 只能連正式環境資源 有自己的設定、密鑰、綁定
Durable Objects 狀態 跟正式共用 每個預覽獨立
管理方式 — 同一個 Worker 內,在後台切換

官方特別點出:以前用 Wrangler environments 做多環境,每個環境都要部署、管理一個獨立的 Worker;Previews 則把隔離環境放在同一個 Worker 底下。

給開發者的技術細節

在 Wrangler 設定檔加一個 previews 區塊,當作所有預覽的「基礎設定」:

{
  "vars": { "ENVIRONMENT": "production" },
  "r2_buckets": [{ "binding": "UPLOADS", "bucket_name": "prod-uploads" }],
  "previews": {
    "vars": { "ENVIRONMENT": "preview" },
    "r2_buckets": [{ "binding": "UPLOADS", "bucket_name": "r2-staging" }]
  }
}
  • 每個預覽會先複製這份基礎設定,也可以只針對某一個預覽覆寫(例如改連它自己的測試資料庫)
  • Durable Objects 透過 ctx.exports 存取:正式環境會對應正式命名空間,預覽則對應自己的命名空間
  • 搭配 Browser Run、Playwright MCP 與 Workers Observability MCP,可以讓 AI 代理自己開預覽網址、點流程、查追蹤資料、修正再重新部署

目前的限制(官方說正在改善):

  • 預覽裡的服務綁定,呼叫的仍是被綁定 Worker 的正式部署
  • 預覽可以送訊息到 Queue,但不能消費;Workflow 執行要另外設定才能隔離
  • 長期存在的 staging、QA 環境支援還在規劃中

我的看法

接案時最常見的需求之一,就是「先給客戶看新功能長什麼樣子」。以前要嘛開一台測試機,要嘛直接在正式站藏一個頁面,兩種都有風險。Worker Previews 讓每個功能分支都有一個可以丟給客戶看的網址,再用 Access 鎖起來,流程乾淨很多。

要注意的是「隔離」沒有到 100%:服務綁定和 Queue 目前仍可能碰到正式環境。所以一開始就要在 previews 區塊把資料庫、儲存空間都指向測試資源,不要以為開了預覽就萬無一失。

名詞小辭典

  • Git 分支(Branch):從主程式複製出來的獨立修改線,改完確認沒問題再合併回去。
  • Durable Objects:Cloudflare Workers 裡能保存狀態的元件,每個物件只有一個實例負責它的資料。
  • 可觀測性(Observability):用紀錄、指標與追蹤資料,了解程式在執行時到底發生了什麼事。
  • Cloudflare Access:在網站前面加一道登入關卡,只讓授權的人進入。

資料來源

常見問題

Workers 以前不是就有預覽網址嗎?
以前的預覽網址現在改叫 Version URL,它只是指向某個上傳過的版本,而且只能連到正式環境的資源。Worker Previews 則是替每個分支建立一整套隔離環境,有自己的設定、密鑰與狀態。
預覽環境會不會改到正式資料庫?
Durable Objects 與 Containers 會自動為每個預覽建立獨立的命名空間。其他資源(例如 R2、資料庫)要在 previews 設定區塊裡指向測試用的資源,否則可能還是連到你設定的那一個,建議一開始就把基礎設定指向測試資源。
可以把預覽網址給客戶看,但不公開給所有人嗎?
可以。預覽網址可以掛在自己的網域下(例如 feature-login.previews.example.com),再用 Cloudflare Access 要求訪客先登入,只有授權的人看得到。
LINE