部署上線：選對平台省 80% 的事

一個人做產品第 6 / 18 篇

本篇是「一個人做產品」系列的第 6 / 18 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。

那個毀掉週末的部署：選錯平台的代價

你的 MVP 寫好了。在本機跑得完美無缺。

「接下來就是部署嘛，應該很快。」你這樣想。

然後你打開了 AWS Console。

幾個小時後，你還在跟 IAM 權限、VPC、Security Group 這些設定打轉。CloudFront 的 cache invalidation 生效要等十幾分鐘，HTTPS 憑證又卡在 DNS 驗證。

到了星期天晚上，產品還是沒上線，一整個週末就這樣耗掉了。

如果你有過這種經驗，你犯了 Solo Builder 最常犯的錯：把部署平台當成「寫完 code 之後的小事」。

但對一個人做產品來說，部署平台的選擇可能是僅次於技術棧之後最重要的決定。選對了，git push 就上線。選錯了，光是搞部署就吃掉你一半的可用時間。

部署的 80/20 法則

先講一個我自己抓的粗估：

一個人做產品，花在「部署相關」工作上的時間，大概佔整體開發時間的三到四成。

先誠實說：這三到四成不是哪份研究的數字，是我自己做過幾個產品抓出來的體感，而且變異很大。一個純靜態部落格可能只花 5%，一個要顧資料庫、金流、排程的全棧 SaaS 衝到一半也不奇怪。所以這個數字你別當成普世統計，當成「這件事比你以為的吃時間」的提醒就好。標題那個「省 80%」也是同樣的意思——是個讓你記住重點的講法，不是承諾。

這包括：

初始設定（CI/CD pipeline、環境變數、域名、SSL）
除錯（「為什麼本機可以跑但 production 不行？」）
維運（監控、log 查看、擴容、更新）
成本管理（帳單、用量追蹤、方案升級）

在一個有 DevOps 團隊的公司，這些事有專人處理。但你只有一個人。你花在部署上的每一分鐘，都是從開發功能和寫內容的時間裡偷來的。

所以選對平台才這麼重要，你要的就是一個能把部署時間大幅省下來的平台。

理想的狀態是：

你寫程式碼 → git push → 自動建置 → 自動部署 → 上線

中間不需要你做任何事。不需要手動觸發。不需要 SSH 進 server。不需要更新 Docker image。不需要清 cache。

2026 年，這個理想是完全可以實現的。但前提是你要選對平台。

三大平台比較

Solo Builder 在 2026 年最常用的部署平台有三個。每個都有明確的適用場景。

選項 1：Cloudflare Workers + Pages

一句話：邊緣運算全家桶，免費額度最慷慨。

Cloudflare 的開發者平台在過去幾年進化成了一個完整的生態系。不只是 CDN——它提供運算（Workers）、靜態託管（Pages）、資料庫（D1）、物件儲存（R2）、鍵值存儲（KV），全部整合在同一個平台。

核心優勢：

零冷啟動：Workers 在全球 330+ 邊緣節點運行，沒有傳統 serverless 的冷啟動問題
免費額度極其慷慨：10 萬次 request/天、10 GB R2 儲存、5 GB D1 資料庫
部署速度快：全球部署通常在 30 秒內完成
全家桶整合：計算、儲存、資料庫、CDN 全在一個 dashboard 管理
Wrangler CLI：一個指令搞定所有事

適合的產品類型：

靜態網站、部落格、文件站（Pages）
API 服務（Workers）
全棧應用（Workers + D1 + R2）
任何需要全球低延遲的服務

不適合的場景：

需要長時間運行的任務（Workers 有 CPU 時間限制）
需要傳統 SQL 資料庫功能的應用（D1 是 SQLite，不是 PostgreSQL）
需要 WebSocket 長連接的即時應用（需要 Durable Objects，設定較複雜）

先說清楚鎖定這件事（我等等講 Cloud Run 會誇它「沒有廠商鎖定」，但全家桶剛好相反）： 你只用 Pages 放靜態網站，幾乎沒有鎖定，要走隨時走。可是一旦你照我建議「全棧就上 Workers + D1 + R2」，你就是在簽一份解約很貴的合約。Workers 跑的不是完整 Node.js runtime，很多 npm 套件和原生模組直接不能用，你的程式碼是寫給 Workers 的、不是寫給 Node 的；D1 是 Cloudflare 自家的 SQLite，KV 和 Durable Objects 更是別的平台根本沒有對等品；R2 雖然標榜 S3-compatible，但 binding 寫法是專屬的。前端框架換平台只是換 adapter，這些東西換平台是重寫。我自己還是用，因為免費額度跟 DX 真的香——但你要知道你綁的是哪一個，別以為三個平台的鎖定程度一樣。

選項 2：Vercel

一句話：前端框架的最佳夥伴，開發者體驗一流。

Vercel 是 Next.js 的母公司，自然是 Next.js 部署的首選。但它也支援 Astro、Nuxt、SvelteKit 等框架。

核心優勢：

框架整合最深：尤其是 Next.js，幾乎零設定
Preview Deployments：每個 PR 自動生成預覽環境
Edge Functions：支援邊緣運算
Analytics：內建 Web Vitals 監控
開發者體驗：Dashboard 好看好用

適合的產品類型：

Next.js 應用（天然搭配）
需要 SSR 的動態網站
需要 Preview Deployments 的團隊協作（雖然你是一個人，但對 review 很方便）

不適合的場景：

需要後端 API 的全棧應用（Vercel 的 serverless function 有冷啟動和執行時間限制）
頻寬密集型應用（免費方案 100 GB/月，超過開始收費）
需要資料庫的應用（需要外接 Supabase、PlanetScale 等）

選項 3：Google Cloud Run

一句話：把容器丟上去就能跑，介於 serverless 和 VPS 之間。

Cloud Run 是 Google Cloud 的容器化 serverless 服務。你給它一個 Docker container，它幫你跑起來，自動 scale。

核心優勢：

任何語言都能跑：只要能打包成 Docker container
真正的 serverless：沒有流量時 scale to zero，不收費
彈性最大：可以跑任何框架、任何語言、任何架構
GCP 整合：如果你已經在用 GCP 的其他服務（Cloud SQL、Cloud Storage）
沒有廠商鎖定：標準 Docker container，隨時可以搬到其他平台

適合的產品類型：

已經有 Docker 化的應用
需要跑非 JavaScript 語言的後端（Python、Go、Rust）
需要長時間運行或計算密集的任務
需要 PostgreSQL 的全棧應用（搭配 Cloud SQL）

不適合的場景：

簡單的靜態網站（殺雞用牛刀）
完全不想碰 Docker 的人
不需要 GCP 生態系的人（設定比前兩者複雜）

詳細比較表

免費額度比較

項目	Cloudflare Workers + Pages	Vercel	Cloud Run
請求數	10 萬次/天	無限（有頻寬限制）	200 萬次/月
頻寬	無限（靜態）	100 GB/月	1 GB/月
計算時間	10ms CPU/次	100 GB-hours/月	180,000 vCPU-秒/月
建置次數	500 次/月	6,000 分鐘/月	—
資料庫	D1: 5 GB	需外接	Cloud SQL 無免費額度
物件儲存	R2: 10 GB	需外接	Cloud Storage: 5 GB
自訂域名	✅ 免費	✅ 免費	✅ 免費
SSL	✅ 自動	✅ 自動	✅ 自動
CDN	✅ 全球 330+ 節點	✅ 全球	❌ 需另外設定

開發者體驗比較

項目	Cloudflare	Vercel	Cloud Run
設定到部署時間	5 分鐘	3 分鐘	15-30 分鐘
git push 自動部署	✅	✅	✅（需設定 Cloud Build）
Preview Deployments	✅	✅	❌ 需自建
CLI 品質	⭐⭐⭐⭐ wrangler	⭐⭐⭐⭐⭐ vercel	⭐⭐⭐ gcloud
Dashboard	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
文件品質	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
AI 友善度	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐

成本升級比較（超出免費額度後）

用量等級	Cloudflare	Vercel	Cloud Run
小型（1,000 DAU）	$0（免費額度內）	$0（免費額度內）	~$0-5/月
中型（10,000 DAU）	$5/月（Workers Paid）	$20/月（Pro）	~$10-30/月
大型（100,000 DAU）	$5-25/月	$20-150/月	~$50-200/月

Cloudflare 的付費方案從 $5/月的 Workers Paid Plan 起跳，包含 1,000 萬次 request。性價比極高。

決策框架：你的產品該選哪個

不要比較二十個維度。問自己三個問題就夠了：

問題 1：你的產品是什麼類型？

產品類型	推薦平台	原因
靜態網站 / 部落格	Cloudflare Pages	免費、快、零設定
Next.js 應用	Vercel	原生支援、零設定
API 服務	Cloudflare Workers	免費額度大、零冷啟動
全棧 SaaS（JS）	Cloudflare Workers + D1	全家桶、一站式
全棧 SaaS（需要 PostgreSQL）	Cloud Run + Cloud SQL	最彈性
計算密集型	Cloud Run	沒有 CPU 時間限制

問題 2：你在第 3 章（技術選型決策框架）選了什麼技術棧？

如果你照第 3 章的建議選了 TypeScript + Astro → Cloudflare。如果你選了 Next.js → Vercel。如果你用 Python、Go 或其他語言 → Cloud Run。

問題 3：你願意花多少時間在部署上？

零時間：Cloudflare Pages 或 Vercel（git push 就上線）
一小時：Cloudflare Workers（需要寫 wrangler.jsonc）
半天：Cloud Run（需要寫 Dockerfile、設定 Cloud Build）

AI 輔助部署：傳統做法 vs. AI 加持

部署設定是 AI 最能幫忙的環節之一。因為部署設定大部分是「照著文件抄設定檔」——這種結構化、模式化的工作，AI 做得又快又準。

傳統做法

讀平台文件（30 分鐘）
複製範例設定檔，開始修改（20 分鐘）
第一次部署失敗，看錯誤訊息（10 分鐘）
Google 錯誤訊息，找到 Stack Overflow（15 分鐘）
修改設定、再部署（10 分鐘）
又失敗，不同的錯誤（10 分鐘）
重複步驟 4-6 三次（45 分鐘）
終於成功

→ 合計約 2-3 小時

AI 加持做法

Step 1：讓 AI 生成完整的部署設定

以 Cloudflare Workers 為例：

我的專案：
- 框架：Astro 6
- 功能：靜態部落格 + 少量動態 API（搜尋、聯絡表單）
- 資料庫：D1 (SQLite)
- 檔案儲存：R2
- 目前在本機用 npm run dev 可以正常運行

請幫我生成部署到 Cloudflare Workers + Pages 需要的所有設定：

1. wrangler.jsonc（包含 D1 和 R2 bindings）
2. GitHub Actions workflow（push to main 自動部署）
3. 需要設定的環境變數清單
4. 部署前的 checklist

Step 2：讓 AI 預測可能的問題

基於剛才的設定，請列出部署時最可能遇到的 5 個問題，
以及每個問題的解決方法。

特別注意：
- Astro 在 Cloudflare Workers 上的已知限制
- D1 的 binding 設定常見錯誤
- 環境變數在 production 和 development 的差異

Step 3：部署失敗時讓 AI 診斷

部署失敗了，以下是錯誤訊息：

[貼上完整的錯誤日誌]

我的設定：
- wrangler.jsonc: [貼上]
- package.json 的 build script: [貼上]

請分析失敗原因，並給出具體的修復步驟。

用 AI 輔助，整個部署過程通常 30 分鐘內搞定——包括遇到問題和解決問題。

零設定部署：git push → 自動上線

一旦初始設定完成，之後的每一次部署都應該是自動的。對 Solo Builder 來說這是核心需求，你不會想每次更新都要手動操作。

Cloudflare Pages 的自動部署

最簡單的方式是連接 GitHub repo：

在 Cloudflare Dashboard 建立 Pages 專案
連接你的 GitHub repo
設定建置指令（npm run build）和輸出目錄（dist）
完成

之後每次 push 到 main，Cloudflare 自動建置並部署。每個 PR 還會生成一個預覽 URL。

GitHub Actions + Wrangler

如果你需要更多控制（例如部署前跑測試、部署後做 health check），用 GitHub Actions：

# .github/workflows/deploy.yml
name: Deploy to Cloudflare

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v6
        with:
          node-version: 22

      - run: npm ci
      - run: npm run build
      - run: npm run test

      - name: Deploy
        uses: cloudflare/wrangler-action@v4
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: deploy

這個 workflow 做了四件事：安裝依賴、建置、跑測試、部署。全自動，不需要你動手。

部署後驗證

自動部署之後，加一步自動驗證：

- name: Health Check
  run: |
    sleep 15
    STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://your-site.com)
    if [ "$STATUS" != "200" ]; then
      echo "Health check failed with status $STATUS"
      exit 1
    fi
    echo "Health check passed!"

如果部署後網站不正常，GitHub Actions 會顯示失敗。你可以在 GitHub 設定通知，部署失敗時收到 email。

真實案例：bobo-blog 的部署架構

讓我用 bobo-blog（就是你正在看的這個部落格）的真實部署設定來說明。

架構

GitHub repo → GitHub Actions → Cloudflare Workers
                                    ├── Pages（靜態資源）
                                    ├── Workers（動態路由）
                                    └── wrangler.jsonc（設定）

為什麼選 Cloudflare Workers 而不是 Cloudflare Pages

bobo-blog 用的是 Astro + Cloudflare Workers adapter，而不是純 Pages。原因是：

動態路由：部落格有搜尋功能、聯絡表單等需要伺服器端處理的功能
Headers 控制：需要精細的 cache control 和 security headers
未來擴充：如果要加 API（例如訂閱功能），Workers 已經準備好了

純靜態的部落格用 Pages 就夠了。但如果你的產品有任何動態需求，建議一開始就用 Workers。

部署設定

// wrangler.jsonc（精簡示意，對齊本部落格實際設定）
{
  "name": "bobo-blog-repo",
  "main": "worker/index.ts",
  "compatibility_date": "2025-12-21",
  "compatibility_flags": ["nodejs_compat"],
  "assets": {
    "binding": "ASSETS",
    "directory": "./dist/client",
    "not_found_handling": "404-page"
  }
}

就這麼簡單。沒有 Docker、沒有 Kubernetes、沒有 load balancer、沒有 reverse proxy。

一個 JSON 設定檔，wrangler deploy 一個指令，30 秒內全球部署完成。

部署流程

我 push 到 main
    ↓
GitHub Actions 觸發
    ↓
npm run build（Astro 建置，約 30 秒）
    ↓
wrangler deploy（部署到 Cloudflare，約 15 秒）
    ↓
Health check 確認網站正常
    ↓
完成

從 push 到上線：不到 2 分鐘。

成本

到目前為止：$0/月。

全部在免費額度內。靜態資源的頻寬不計費。Workers 的 10 萬次/天免費 request 對一個個人部落格來說綽綽有餘。

什麼時候會開始花錢？大概要到每天超過 10 萬次請求。以一個部落格來說，那已經是非常成功的流量了。到那時候，$5/月的 Workers Paid Plan 就夠用了。

環境變數和密鑰管理

部署時最容易出包的地方之一：環境變數。

常見的坑

本機有但 production 沒有：你在 .env.local 設了 API key，但忘了在部署平台設定
格式不對：有些平台不支援 .env 檔案的某些語法
密鑰洩漏：不小心把 .env commit 到 GitHub

環境變數 Checklist

在部署之前，用 AI 幫你檢查：

以下是我的 .env.local 檔案（已遮蔽敏感值）：

DATABASE_URL=d1://xxx
R2_BUCKET=my-bucket
STRIPE_SECRET_KEY=sk_test_xxx
SITE_URL=https://my-site.com

我要部署到 Cloudflare Workers。
請幫我：
1. 列出哪些變數需要在 Cloudflare Dashboard 設定
2. 哪些變數用 secrets（加密），哪些用普通 variables
3. 哪些變數在 production 和 development 的值不同
4. 確認 .gitignore 有正確排除 .env 檔案

什麼時候該升級：超出免費額度的信號

免費額度不會永遠夠用。以下是你該考慮升級的信號：

信號	代表什麼	該怎麼做
免費 request 用量超過 70%	流量在成長	評估付費方案
建置頻繁失敗	建置次數接近上限	減少不必要的 push 或升級方案
冷啟動開始被用戶抱怨	流量模式不適合 serverless	考慮 always-on 選項
資料庫大小接近上限	資料在成長	評估付費方案或清理舊資料
你花時間在優化免費額度而非產品	優先順序錯了	直接升級，把時間花在有價值的事上

最後一點最重要。如果你發現自己在花時間「省部署費用」，那就直接付費。 你的時間比每月 $5-20 的雲端費用值錢得多。

部署平台遷移：沒你想的那麼難

如果你選錯了，不要害怕換。

大部分現代框架（Astro、Next.js、SvelteKit）都支援多個部署平台。換平台通常只需要：

換一個 adapter（例如 @astrojs/cloudflare → @astrojs/vercel）
調整設定檔（wrangler.jsonc → vercel.json）
在新平台設定環境變數
指向新的部署 URL

整個過程大約 1-2 小時。不是不可逆的大手術。

但「1-2 小時」只在一種情境成立，我得把話講準，免得你被我害到：

情境一：純靜態或 SSR 前端、沒有自己的資料庫和儲存。 換 adapter、改設定、重設環境變數，1-2 小時真的搞得定。你只是搬一個會自己重新 build 的網站。
情境二：你照前面建議上了全棧（D1 資料庫、R2 儲存、Workers 專屬 runtime）。 這不是 1-2 小時，這是好幾天到一兩週的工程：D1 的 SQLite 要匯出再匯進別人的 PostgreSQL，schema 和語法會打架；R2 的檔案要整批搬、舊 URL 要重寫；Workers-only 的程式碼要改回能在 Node 跑；secrets 全部重設；最後 DNS 切換還有停機風險。

所以這句「沒你想的那麼難」只適用情境一。情境二剛好相反——它難到會回頭懲罰你早期的架構決定。不要在選平台上糾結太久沒錯，但也別因為「反正以後好搬」就閉著眼睛把核心資料綁進某個平台。前端可以先上線再說，資料層值得你多想十分鐘。

本章重點回顧

🏗️ 部署平台的選擇對 Solo Builder 比團隊更重要——你沒有 DevOps 團隊，選錯了你要自己扛
📊 三大平台各有所長：Cloudflare（全家桶 + 最慷慨免費）、Vercel（最佳 DX + Next.js 首選）、Cloud Run（最彈性 + Docker 通吃）
💰 免費額度是你的跑道——Cloudflare 和 Vercel 都能讓你在驗證 PMF 之前零成本營運
🤖 AI 可以在 30 分鐘內幫你搞定完整的部署設定，包括 CI/CD pipeline 和環境變數
🔄 理想部署流程：git push → 自動建置 → 自動部署 → 自動驗證，中間不需要你動手
⏱️ 不要糾結太久——選一個先上線，真的不合適再換。但「好搬」只算純前端（換 adapter，1-2 小時）；有資料庫和儲存的全棧要搬是好幾天的工程，這部分早點想清楚

下一步

產品部署上線了。

但上線不是終點——如果沒人知道你的產品存在，零流量跟沒上線沒有兩樣。

下一章，我們來解決「讓產品被找到」的問題：怎麼用 AI 快速做出有轉換力的 Landing Page，以及怎麼建立一套讓 Google 幫你持續帶來免費流量的 SEO 策略。

👉 第 7 章：Landing Page 與 SEO——讓產品被找到

那個毀掉週末的部署：選錯平台的代價

部署的 80/20 法則

三大平台比較

選項 1：Cloudflare Workers + Pages

選項 2：Vercel

選項 3：Google Cloud Run

詳細比較表

免費額度比較

開發者體驗比較

成本升級比較（超出免費額度後）

決策框架：你的產品該選哪個

問題 1：你的產品是什麼類型？

問題 2：你在第 3 章（技術選型決策框架）選了什麼技術棧？

問題 3：你願意花多少時間在部署上？

AI 輔助部署：傳統做法 vs. AI 加持

傳統做法

AI 加持做法

零設定部署：git push → 自動上線

Cloudflare Pages 的自動部署

GitHub Actions + Wrangler

部署後驗證

真實案例：bobo-blog 的部署架構

架構

為什麼選 Cloudflare Workers 而不是 Cloudflare Pages

部署設定

部署流程

成本

環境變數和密鑰管理

常見的坑

環境變數 Checklist

什麼時候該升級：超出免費額度的信號

部署平台遷移：沒你想的那麼難

本章重點回顧

下一步

相關文章

技術選型決策框架

部署上線：從 Laravel Forge 到容器化的三條路

Cloudflare Pages 的 20,000 檔案上限：當「一頁一檔」撞牆，我把 TaxMap 搬到 Netlify

留言討論