從製作公司的角度整理 Cloudflare

什麼是 Cloudflare？從製作公司的角度了解其特色、功能與適用場景

Cloudflare 這個名字已經相當知名，但它實際能做什麼，卻常常是模模糊糊的理解。老實說，在不久之前，很多對話可能只停留在「那是 CDN 公司吧」，去年的故障也可能讓一些人第一次認識它。
或許很多懂行的人已經了解，但我們這樣的公司、以及負責專案的負責人，究竟該如何運用它，在此做個整理。

Cloudflare 不只是為了讓網站瀏覽更快的機制，它還具備 DNS、WAF、身分驗證控制、無伺服器執行、靜態網站託管、檔案儲存、日誌接收，以及 AI 相關等相當多元的功能。

從製作公司的現場來看，這點相當重要。
因為在專案中，光是「把網站顯示出來」並不算完成。預備環境要如何隱藏、日誌要送往何處、圖片與附件要放在哪裡，這些細節每次都會出現。

Cloudflare 的便利之處在於，相關功能比較容易整合成一個統一的架構。當然，不必把所有東西都集中在 Cloudflare，依專案不同，搭配 Supabase、AWS 會更自然。
不過，若想讓架構更輕量，或希望設計方便向客戶說明，它會是相當有力的選項。

特別是企業網站、招募網站、自有媒體，以及包含部分會員導引的網站，Cloudflare 通常很合適。對於偏重前端的公司來說，它的優點在於不只是基礎設施的話題，也能自然延伸到實作層面，使用起來相當順手。

您不需要一開始就記住 Cloudflare 的所有產品名稱。反而可以把它理解為「一個幫您統整管理網站入口周邊服務的平台」，這樣會輕鬆很多。

舉例來說，從瀏覽器端來看，最先經過的是 DNS；負責快速傳遞內容的是 CDN；阻擋可疑存取的是 WAF；只保護特定頁面的是 Access；執行輕量處理的是 Workers；靜態內容發佈的是 Pages；檔案儲存的則是 R2。Cloudflare 在 Web 周邊的各種功能上，涵蓋範圍相當廣。

這大概可以稱為「跨領域的整合感」吧。
在專案中，網站呈現、維運、資安、更新流程、限定公開、日誌紀錄、AI 應用等環節往往環環相扣，而 Cloudflare 的優勢就在於能夠把這些部分整理得井井有條。

Cloudflare 對於製作公司與前端實作公司來說，相當契合。
即使不需要規劃厚重的雲端架構，也比較容易建立範圍適中的系統配置。

舉例來說，以 Astro 建置企業網站並部署到 Cloudflare Pages，部分限定頁面以 Access 設限，聯絡表單透過 Workers 寄送郵件，附件則存放於 R2，這樣的架構相當自然。
雖然也可以把這些功能各自使用不同服務來組合，但依專案規模而定，有時會顯得有些過度。

服務一多，交接與維護時的複雜度就會浮現出來。若集中使用 Cloudflare，通常能在一定程度上控制這種複雜度。

這裡需要稍微冷靜地看待。
Cloudflare 雖然方便，但並非所有東西都集中到 Cloudflare 才是正解。

若專案的應用程式邏輯相當繁重、以複雜的資料庫設計為核心，或是已經明確決定採用其他雲端基礎架構，那麼不以 Cloudflare 為主體可能會更自然。有些情況下，Vercel 更符合開發體驗；而有些情況下，AWS 在整體後端規劃上則更容易思考。

這不是因為它萬能才使用，而是要看您希望在哪些部分「輕量化、強化或整理」來選擇。在網站發布、入口安全防護、輕量執行環境、限定公開與儲存等面向，它的優勢相當明顯。

Cloudflare 較適合以下類型的專案。

若是正式的 SaaS 或業務系統等以應用程式為核心的專案，則不宜只單獨考量 Cloudflare，還需評估如何與其他基礎架構（例如 Supabase）搭配使用。

這部分過去需要大量比對服務資料與文件，只能在腦中自行整理，但近來情況已有很大改變。

若與 Claude Code 或 Gemini 討論「這項需求會涉及 Cloudflare 的哪些功能」、「如何切分預備環境的保護與表單基礎架構」等觀點，最初的整理速度非常快。
比較表的初稿與議題的梳理也明顯輕鬆許多。

責任分界、營運體制、稽核要件、更新負責人的理解程度等，最終都必須由人工確認，否則風險很高。LLM 負責繪製最初的地圖，人類負責選擇符合現場需求的路線，我認為這樣的角色分工最為恰當。

若要用一句話形容 Cloudflare，它不只是單純的加速服務，而是能廣泛支撐網站周邊各項功能的平台。從製作公司的角度來看，當您想「簡化架構」，同時又希望確實保有必要的防護與實作能力時，它的效果相當顯著。

當然，並非所有情況都適合只選 Cloudflare。
從網站內容配送、身分驗證控制、輕量後端、儲存空間，到 AI 應用的入口，它能夠一併涵蓋，這是很大的優勢。實際使用後，我想您的印象應該會有很大改變！設定其實非常簡單！