如何架設 Blog？

2026年7月19日· 約 12 分鐘閱讀

在前一篇，我說明了框架怎麼選，空有框架不夠，要有地方跑我們的 Blog 對吧？

所以這裡會探討哪裡可以架設網站，還有哪些方案？

雲託管#

這是絕對的市場大宗，因為多數人不會自己維護 Server，因為無論是設備維護、網路設定，還是前期的硬體購入都是較高的成本。
網頁這塊，恰好是個最適合上雲還幾乎低成本甚至零成本的地方 (對於 Blog 而言，確實可以做到零成本)。

NOTE

這裡的雲託管是指託管「服務」這一塊。
所以 AWS、Azure 或其他 VPS 服務，對於你有整臺機器控制權的服務，在這篇文章不會列為雲託管，而是列為 Self-host。

最無腦選擇#

要我說最無腦的選擇，那就是 GitHub Pages。
阿？為什麼？

你想一下，你只要碰到「開發」，你一定會需要遠端同步 Code 的地方對吧？
大多人用什麼？不是 Google Drive，就是 GitHub 對吧？技術力過關的團隊，基本都是用 GitHub 來同步 Code。

所以合格的開發者，人手一個 GitHub 帳號是很正常的 (前陣子的 Nightmare-eclipse 是特例)。
也因此你要用 GitHub 建立網站，非常容易，這套方案，就是我們的 GitHub Pages。

這裡我們先排除企業方案，只看一般人的部分。

付費與否只會影響儲存庫 <yourname>.github.io 是否可以是私人狀態，其餘以下限制無論付費與否不影響：

每個帳號只能建立一個站臺
儲存庫大小不得超過 1G
編譯完後的網頁總和不能超過 1G
每個月 100G 軟性頻寬上線
請求過於頻繁，有幾率收到 429
每小時 10 次 build 上限 (自定 GitHub Actions 則不受影響)

使用限制也是，只能用於免費網站，不能用 GitHub Pages 建立盈利網站。

當然，你也不能用 GitHub Pages 公開密碼、信用卡號等私密資訊，也不能寫服務條款規定的快速致富方法、色情或暴力威脅內容。

講真，看到這麼多限制，然後付費只是換取可以用私人儲存庫架站，底下的主流雲託管都比較強。

順帶一提，GitHub Pages 還是純靜態網站，連寫 SSR 或者其他動態網站都不行，如果想寫動態網站，也得 bypass GitHub Pages。

但如果對於玩票、不介意公開 Blog 儲存庫更新狀態的人，或者就是應付學校作業，且不是寫動態網站，那確實很夠。

GitHub Pages 就是勝在大家都有 GitHub 帳號，如果你想認真經營網站，或甚至寫能盈利的網站，下面有更好的選擇。

補充一下，GitHub 本身沒有託管服務，他的 GitHub Pages 是會將你 push 到儲存庫的 HTML/CSS/JS 丟到 Fastly。
Fastly 是一家獨立的 CDN 廠商，跟後面會提到的 Cloudflare 是競爭關係。

主流雲託管#

到了這裡，才是大多人會用來架網站的地方，這裡會來介紹三大雲託管。

NOTE

前一篇 Blog 的框架選擇有提到 Ghost Pro，這種特定技術棧的雲託管，不會在以下的討論之內。

Vercel#

先來說說業界最知名的供應商。

搭配獨家產品 Next.js 架設網站，可以獲得絲般順滑的瀏覽體驗。

同時也是早期大力推廣「Preview Deployments」的廠商，但基本上現在的雲託管都具備這功能，沒必要特別為此選 Vercel。

除非你的網站要用 React + Next.js 來寫，不然我十分不推薦 Vercel，我們來看一下他的限制：

	Hobby (Free)	Pro
用途	僅限個人非商業	商用 / 團隊
費用	0$	每人 20$ / 月
頻寬 (Fast Data Transfer)	100 G	1 TB
Edge Request	1M / 月	10M / 月
Active CPU	4 小時 / 月	用多少付多少
Log 保存	1 小時	1 天

你可能看到頻寬 FDT 不是很懂，看到官方表格，還會看到 Fast Origin Transfer。
後者是 Edge Network 往回 Vercel 運算資源 (Vercel Functions、Middleware 或 ISR 等)請求的流量，如果要架設動態網站，這個也要注意，是帳單費用一大來源。
前者才是網頁部署後， Edge Network 與終端使用者的流量。

惡劣的點來了，以 Hobby 為例，假如你的 Blog 夠多人看，傳輸量到了 100G，你的 Blog 這個月直接下線，等下個月重新記帳才會重新上線。

如果你是想弄一套動態網站，這裡我引用 vendr 的數據，一個小團隊 (5 ~ 20 人)，訂閱 Vercel Pro 方案，每年至少花費 $1200 ~ $4800 USD，還要外加 $500 ~ $3000 USD 的額外費用 (比如 FOT 流量或 CPU 時間)。

Vercel 憑什麼這麼貴？因為他的底層是 AWS Lambda，然後配上自己寫的 Serverless 實作、Vercel 專屬抽象前端等，所以你付的錢，有一部分是「AWS 稅金」。
當然這是簡短的講，Vercel 也是有自己的 CDN，不全是堆在 AWS 上，但是，對，那帳單夭壽貴。

就算是用 Next.js，FOT 和 AWS 稅金一樣要付，你選 Vercel 買的不是「比較便宜」，而是那些原生整合的開發體驗。

Netlify#

這家供應商我反而最不熟，所以我當初沒考慮，為了寫這篇文章來補課。

Netlify 現在的狀態…被稱為老二，排在 Vercel 之後，這裡沒算上 Cloudflare，因為他們的核心客戶並不一樣。

Netlify 是 composable (可組合的) web platform，把靜態資源建置、全球分發和後端邏輯 (serverless/edge functions) 解耦。
Netlify 還有一個賣點是，他對任何技術棧的網頁都十分中立，不像是 Vercel 圍繞 Next.js 設計核心服務，也不像 Cloudflare 一樣收購 Astro。
除此之外，內建功能相比 Vercel 也比較多，比如表單處理、身份驗證等功能。

同樣支持 branch preview，在計費方式對比 Vercel 大多獨立計算，Netlify 是用 Credit 消耗機制來算的。
比 Vercel 還摳，讓我來算個帳：

方案	價格	額度 (Credit)	備注
Free	$0	300	約等於 15G、20 次 production deploy
Personal	$9 USD / 月	1000	僅限個人使用，可以 auto recharge (自動補充 Credit)，加購以 500 credit / $5 USD 來補充
Pro	$20 USD / 月	3000 (可加購至 20000)	免費無限團隊席位，加購以 1500 credit / $10 USD 來補充

然後你要知道，Credit 這套機制是所有服務共用，講好聽點，就做靈活調度，講難聽點，就是共用資源。
然後你會看到，單看 Netlify 給的 Credit，哪怕是全部給流量或者部署，都不如 Vercel，難怪當老二？

但 Netlify 哪怕是 Free Plan，都允許你盈利，Vercel 的 Hobby 只允許個人、非營利使用。
除此之外 Netlify 目前主要往企業的合規功能發展，想跟 Vercel 錯開市場。

如果你要用 Netlify，只有兩種情況我會推薦：

你想要盈利，但又想用免費方案架網站
你有團隊，那 Netlify Pro 不限定人數，假設 5 人，那 Vercel Pro 和 Netlify Pro 的價格比較大概是 $100 vs $20 (基礎訂閱)

至於 Personal 方案…除非你有想要盈利，但 Netlify Free 又給太少，或者你真的預算很有限，不然這方案的價值就是解鎖 auto recharge 而已…

最後補充一下，跟 Vercel 一樣，Credit 用完之後，你的服務會直接從網路上消失，直到下次帳單週期 (或者你補充 Credit 之後)。

Cloudflare Worker / Pages#

這是一個基礎建設平臺，能力外溢到 Web 服務的項目。
Cloudflare Worker 最初就是能跑腳本的 CDN，變成通用的全端應用平臺。
與此同時，還有 Cloudflare Pages，直接跟 Vercel 和 Netlify 這類 Jamstack 全流程平臺(git push → 自動建置 → CDN 部署 → preview URL)競爭。

但有意思的是，Cloudflare Pages 一開始有獨立計費，因為他是靜態網站託管，但加入 Pages Functions (動態邏輯)後，這一部分屬於 Worker 的計費。
這就發生了一件事，那就是管理界面的分裂，靜態網站沒事，但動態網站，看網站本身在 Pages，看動態邏輯在 Worker。
而且靜態網站編譯完，同樣也是要丟到 CDN 上，所以後續 Worker 和 Pages 自然會互相借鑑、整合。

到了現在 2026，Worker 變成靜動態都能跑，Pages 變成了「維護狀態」，Pages 的功能被併入到 Worker，新功能也是都放在 Worker 上。

因為 Worker 功能真的很多，所以我這裡就放到 Blog 比較需要在意的。

首先，CPU 時間執行 Worker 程式碼時才會消耗，I/O 等待不會計算。

Request 更是只算有觸發 Worker 程式碼的請求，Free Tier 是每日 10 萬次請求限制 (UTC 午夜重置)，付費方案 $5 USD 每月才是 1000 萬次，並且超過可額外追加 100 萬次 / $0.30 USD。

如果你真的有動態路由，Free Tier 這每日 10 萬次額度用完，多的請求會直接被擋下來 (Error 1027)，要等到 UTC 午夜重置才會恢復；付費方案則沒有這個每日上限，超過的部分純粹計費，不會被擋。

與此同時， Cloudflare 完全不對流量計費，所以你如果是像我這種純靜態 Blog，完全不用擔心服務離線，也不會增加 Request 計算。

Worker 的計費全都圍繞在動態服務之上，所以如果你有要用 Cloudflare 做 /api/* 動態路由，或者 CMS，才需注意 Worker 的限制。

我要怎麼知道我有沒有跑 Worker 程式碼？

好問題！在 wrangler.jsonc 裡面，用 main 指定的部分，才算是 Worker 程式碼，比如預設的 "main": "dist/_worker.js/index.js"。
至於 assets 是靜態資源，Worker 收到請求後，只會負責傳遞資料給 Client，無論 HTML、PHP還是 JS 等，Worker 都不會執行，由 Client 收到後自己處理。

再來是 CPU build 時間， Free tier 有 3000 分鐘 / 月，夠我養好幾個 Blog 或 SSG了！

然後對於 Repo 大小沒有限制，只有單檔不可超過 25 MiB，以及檔案數量限定在 20000 以內。

需要注意的是，Cloudflare Worker 如果碰到資料在外部，會有比較多限制，subrequest 次數明顯比在 Worker 用 bindings 呼叫次數少。
除此之外就是延遲的問題，CDN 架構跟定點存取天生互斥，每次連線都要 Handshake。
但實務上，很多人還是會用 Hyperdrive 然後 Worker 連到自己的 PostgreSQL、MySQL 上，看環境需求，沒有絕對。
然後 Cloudflare 一樣不收 egress 出站費用，不像 AWS 會收。

Self-host#

如果你就是討厭「服務放在別人的機器上」，那 Self-host 就是你的歸屬。
我個人沒這麼看重，但我認為 Self-host 是一種「你可以不做，但你不能不會」的技能。

功能目標#

以下就是我的見解，如果我要 Self-host，我會怎麼做。

那首先是 Blog 怎麼架設的部分，不用我說，有一臺 Proxmox VE 可以開一臺 VM 放 Blog 就好。
但是我想還原 Cloudflare 那種「Build 完後，無縫切換新舊網頁」，該怎麼做？

那首先，我第一個想到的是 Container，CI/CD 寫好後，我一 Push，開一個新的 Container，build 完後再把舊的殺掉。
結果我把這套方案拿去問 Claude，「太重了」！

WTF！？現在已經是 Container 都嫌重的時代了嗎？一問才知道，Cloudflare 的架構是 Serverless V8 隔離環境。

V8 隔離和 Serverless#

先來說說什麼是 Serverless？
Serverless 我一開始以為是「無 Server」，不用機器！？喔喔，原來不是，而是指的是可以不用上去操心，我只要管 Code 和帳單就好，Server 的事情讓供應商管就好。
但是 Self-host 的話，供應商就是我自己，所以我還是要管 Server 阿！

那就剩下 V8 隔離和部署切換了。

先說說純網頁為什麼用 V8 隔離會比較好。
如果你只是要跑網頁服務，那 V8 隔離的是 JS / WASM 環境，除非你是希望塞整個 binary，那這樣 Container 可以隔離執行環境，這樣 Container 才有意義。
這屬於隔離強度的不同，以及背後資源消耗量的不同，同樣也是工程取捨。

然後 V8 隔離目前市面上有 3 個方案：workerd、isolated-vm 和 Deno。

isolated-vm 是 Node.js 的函式庫，在單一 Node.js Process 隔離 V8 環境，如果 V8 有漏洞，那隔離就不保證，如果是想做資安沙盒，請至少看向 Container。

Deno 嚴格來說是 Node.js 替代品，如果 Deno 要做 V8 隔離部署，這塊反而要上他們家的雲託管才能用，拉倒，下一個。

workerd 這名字也太眼熟了吧…沒錯，就是 Cloudflare Worker 的核心組件，Cloudflare 官方自己開源，可以跑一整套 Serverless 環境。
但是需要注意的是，workerd 只是原始引擎，Worker 的隔離工程、資安圍欄還是要自己疊，但至少可以做到比 isolated-vm 完整，也比 Deno 好做很多。
而且你也可以走混合架構，也就是半套 Cloudflare (KV、D1 等)，API 都在上面。

CI/CD#

但還有一個問題是 CI/CD，workerd 並不具備那套 build 完後，無縫切換部署的功能。

這屬於 CI/CD 的範疇，在 Cloudflare 上，這屬於 Wrangler 的設計。
那看來要麼寫 GitHub Actions，不然要請出老將…Jenkins。

也許不用這麼麻煩，不知道 IaC 可不可以做到，但是 CI/CD 這塊確實是我比較弱的地方。

如果日後真的要 Self-host，我再回來補課 (然後多水一篇文章)。

個人選擇和使用感受#

最後我選的是 Cloudflare Worker。
沒辦法，Cloudflare Worker 拿來架設 SSG 太香了，免費版太多地方能用，根本用不完。
最重要的，流量不算錢，連 Request 碰到靜態資源也不算。
CPU Build 時間我目前消耗量，大約每次是半分鐘至一分半，一週一更的頻率，算上 Astro 更新和 Blog 開發，要用到半小時也很困難。

講到靜態資源，靜態資源的管理反而比較麻煩，之後我會寫到的開發心得會來好好說這件事。

Reference#

本文屬於：Blog and Author › Blog 架設之路 › 架設之前