Wrangler auth profiles：多個 Cloudflare 帳號怎麼避免部署錯環境
同一台電腦同時維護個人網站、客戶專案與 staging Worker 時，最怕的不是 wrangler deploy 失敗，而是它成功部署到錯的 Cloudflare 帳號。Cloudflare 在 2026 年 7 月新增 Wrangler auth profiles：它把具名 OAuth 登入綁定到資料夾，指令在該資料夾及其子目錄執行時會自動選用對應 profile。
結論是：profile 用來選帳號，account_id 用來讓專案設定再做一次明確約束；CI 則繼續使用最小權限 API token。
把帳號綁到專案根目錄
官方提供的基本流程如下。auth create 會建立具名登入；auth activate 則讓某個本機路徑採用該 profile。
# 在終端機完成 OAuth 登入，並選擇可存取帳號wrangler auth create client-awrangler auth create personal
# 將每個專案根目錄綁到不同 profilewrangler auth activate client-a ~/projects/client-awrangler auth activate personal ~/projects/personal-site接下來在 ~/projects/client-a 或其子資料夾中執行 wrangler deploy，Wrangler 會使用 client-a。臨時想覆寫選擇時，再明確指定 profile：
wrangler deploy --profile personal這個機制適合在本機切換帳號；不要把 profile 名稱當成部署環境本身。production、staging 與 preview 仍應由各自的設定、變數和發布流程管理。
在設定檔加上第二道防線
Cloudflare 建議搭配 account_id。這能把「目前登入的是誰」與「這個 Worker 應該屬於哪個帳號」分開驗證。
{ "name": "client-a-api", "main": "src/index.ts", "compatibility_date": "2026-07-22", "account_id": "<CLIENT_A_ACCOUNT_ID>"}先在非正式專案確認 profile 是否真的被選中，再把 account_id 放進 version control。帳號 ID 不是密碼，但在多客戶 repository 中仍應確認它沒有被誤複製到另一個專案。
CI 不會自動改用本機 profile
在 CI 或其他自動化環境裡，CLOUDFLARE_API_TOKEN 的優先順序高於所有 profiles。也就是說，profile 不應取代 CI secret；你仍要為每個部署環境配置權限範圍小、用途單一的 token，並將它放在平台的 secret store。
| 情境 | 建議驗證方式 |
|---|---|
| 本機客戶專案 | 在專案根目錄跑只讀的 Wrangler 指令，確認選到正確帳號 |
| 臨時切換帳號 | 使用 --profile，完成後回到原資料夾再確認 |
| CI | 檢查 CLOUDFLARE_API_TOKEN 對應的帳號與權限，不依賴開發機 profile |
| 部署前 | 設定檔中的 account_id 是否仍屬於該專案 |
如果你的 Worker 還管理 Durable Objects，部署帳號一旦選錯也可能碰到 namespace 的設定與 lifecycle 風險；可接著看 Durable Objects exports lifecycle 的轉換邊界。
profiles 解決的是日常切換時的帳號歸屬，不是完整的權限管理。真正可靠的做法仍是：本機有明確 profile、設定檔有正確 account_id、CI 使用不同且最小權限的 token。
參考資料：
回報錯字、失效連結，或告訴我你想看的延伸主題。