從本機跑到上線，變的是這四件事

同樣一份 code，放到線上要滿足四個本機不需要的條件：

• 機器永遠開著：你的筆電會關、會睡、會斷網。線上要一台 24 小時開著的電腦（雲主機、VPS、或平台幫你顧的機器），你闔上筆電服務也不能停。
• 網際網路連得到：本機是 localhost（只有你這台連得到）。線上要一個公開位址——一個公網 IP，通常再掛一個域名（example.com）指過去，別人才連得到。
• 沒人顧也要活著：本機是你手動 start、崩了你再手動重跑。線上要能開機自動啟動、崩潰自動重啟——半夜掛了不能等你醒來。
• 面對的是真實流量與環境：線上同時被很多人打（並發）、被掃描攻擊（安全）、而且設定跟你本機不同（資料庫位址、密鑰、環境變數都不一樣）。

「部署」這個動作，本質就是把 code 搬到一台滿足這四點的機器上、並讓它以正確的設定跑起來。

一次部署實際包含哪些步驟

把上面四點拆成動作，一次最基本的部署大致是：

1. 準備一台線上機器（或一個幫你跑 code 的平台）——這是「主機形態」要選的。
2. 把 code 送上去——git pull、或打包成 container image 推到 registry（存放 image 的倉庫）再拉下來。
3. 裝好依賴、帶上正確設定——線上的 DB 位址、密鑰用環境變數注入，不是寫死在 code 裡。
4. 讓它開機自動起、崩潰自動重啟——用 systemd、或平台/container 編排器管生命週期。
5. 讓外面連得到——設域名與 HTTPS、開對的 port。

有資料庫的服務還多一步：第一次上線要跑一次 schema 初始化 / migration 把資料表建起來——步驟 3 帶的是「DB 位址」，不等於「DB 裡有表」，漏了這步就是 code 上去了、一連 DB 就爆的典型翻車（migration 屬「一次性 admin process」，每次改資料表結構都要跑）。

常見的誤解是把「部署」等同步驟 2 的「把 code 傳上去」，但真正讓服務「活著且可用」的是其餘幾步。

判讀：你其實已經在部署了

如果你用過 Heroku / Vercel / Render 這種平台按一下就上線，你已經部署過了——只是平台把上面 1、4、5 全包了，你只做了 2、3，也就是平台幫你扛掉大部分部署工作（這正是主機形態光譜的一端）。理解「部署包含哪五步」，是為了在平台包不住、要自己顧機器時，知道每一步在做什麼。

邊界與下一步

這篇講的是「單次把服務弄上線」。真實服務會反覆部署新版本，這時要處理「更新時怎麼不中斷服務」——舊版還在服務、新版怎麼接手、出錯怎麼退回。那是進階的部署策略，見 Backend 部署 rollout / drain / rollback 與 CI/CD。

先搞懂「我的 code 到底該跑在哪」，往下讀 主機形態光譜。

一道光譜，從自己管到平台管

由左（你管最多）到右（平台管最多）：

1你管越多 ←───────────────────────────────────────→ 平台管越多
2裸機/VPS(IaaS)      PaaS              Serverless        全託管 SaaS
3給你一台機器        給你跑 code 的環境  給你跑函式的環境    你只用、不部署
4OS/runtime/DB       platform 管佈署    平台管一切、可縮到零 供應商全包
5/web server 全自己  你只給 code

• VPS / IaaS（DigitalOcean Droplet、AWS EC2、Hetzner）：平台給你一台（虛擬）機器，OS 以上全你自己裝——runtime（語言執行環境，如 Node/PHP）、web server、DB、開機自動啟動、更新。控制權最大，維運工作也最多。
• PaaS（Heroku、Render、Railway、Cloud Run、App Runner）：你把 code（或 container image）交給平台，平台管佈署、擴縮、TLS（HTTPS 憑證）、健康檢查。你不碰機器。控制權少一些，省掉大量維運。
• Serverless / FaaS（AWS Lambda、Cloud Functions、Cloudflare Workers）：你交的是一段函式，平台按請求觸發、沒流量時縮到零、不收錢（指函式本身；後面的 DB、儲存、API gateway 仍照計費）。最省維運，但要遷就它的執行模型（無狀態、有執行時間上限、冷啟動——閒置後第一個請求要等它重新起來），本地開發與除錯也比較麻煩。
• BaaS（backend-as-a-service）（Firebase、Supabase）：連資料庫、認證、後端邏輯層都幫你包，你主要寫前端 + 設定。部署這件事幾乎消失。（再往外就是現成的 SaaS 成品軟體——你只用、連 code 都不寫，那已經不在「部署」的範圍內。）

怎麼在光譜上選位置

選位置看的是「哪個匹配你現在的處境」，沒有絕對最好的一格：

• 想學底層、要完全控制、或有特殊系統依賴 → 偏左（VPS）。你會親手做完部署的五步，學最多，但半夜掛了是你的事。
• 要快速上線、團隊時間比機器費用值錢、不想當維運 → 偏中（PaaS）。丟 code 就上線，平台顧機器。多數小團隊 / 早期產品的甜蜜點；代價是 vendor lock-in、規模長大後費用可能陡升。
• 流量尖峰型或很低、想離峰不花錢 → 考慮右（serverless）。但要接受它的執行模型限制。

注意「省錢」不是單調對應這條軸——它是另一條軸。低流量時 serverless 離峰縮到零反而可能最省；高流量穩定跑時 VPS 的固定成本又划算。所以選位置先看「控制權 vs 維運」，成本另外算，別把「省錢」綁死在某一端。

同一個服務的不同部分可以落在不同位置：app 用 PaaS、DB 用全託管、靜態檔案丟 CDN——這很常見、也常是最省事的組合。

邊界與下一步

主機選好、code 有地方跑之後，接著要讓外面連得到——見 域名與 HTTPS 怎麼接上。

延伸：「app 跑在哪種形態的主機」跟「某個具體元件（DB）要自己顧還是託管」是同一個軸的兩種切法，後者見 自架還是託管：以資料庫為例；「值不值得自建」的商業選型角度見 Backend 交付形態選型；VPS 這一端往上長成「用 IaC 管整套雲端地基」，見 Infra 指南。

域名怎麼指到伺服器：一筆 DNS 紀錄

域名系統（DNS）是「把人記得住的名字翻成機器用的 IP」的電話簿。你在網域註冊商買下 example.com 後，到它（或你用的 DNS 服務）的管理介面，加一筆 A record：

1類型   名稱            值（指向）
2A      example.com     203.0.113.10      ← 你伺服器的公網 IP
3A      www             203.0.113.10

A record 就是「這個名字 → 這個 IPv4」。加完後，全世界查 example.com 會拿到你的 IP、連過來。幾個常見卡點：

• 改了要等生效：DNS 有快取（TTL），改動可能幾分鐘到幾小時才全球生效，不是即時。
• A vs CNAME：A 指向 IP；CNAME 指向「另一個域名」（常用在指到 PaaS 給你的網址，如 myapp.onrender.com）。用 PaaS 時多半是設 CNAME——但裸網域 example.com（apex）依 DNS 規範不能掛 CNAME，只能用 A、或供應商的 ALIAS/flattening，子網域（www）才能 CNAME。這是 PaaS + 裸網域第一次上線的高頻卡點。
• 域名 ≠ 伺服器：買域名跟租主機是兩件事、常在不同供應商。域名只是指標，指向哪台機器由 A/CNAME 決定。

DNS 各紀錄類型的細節見 Infra DNS 卡。

HTTPS 的鎖頭從哪來：TLS 憑證

https:// 前面那個鎖頭代表兩件事：連線被加密（別人竊聽不到內容）、以及對方身分被驗證（你連的真的是 example.com、不是假冒的）。做到這兩點靠的是 TLS 憑證——一份由受信任的憑證頒發機構（CA）簽發、證明「這個域名是這台伺服器的」的檔案。

瀏覽器內建信任一批 CA。伺服器出示 CA 簽的憑證，瀏覽器驗章通過，鎖頭就亮、連線加密。憑證怎麼運作、CA 信任鏈的細節見 Infra SSL/TLS 卡。

憑證怎麼拿：Let’s Encrypt 讓它免費又自動

以前憑證要花錢買，現在 Let’s Encrypt 這個免費 CA 讓它變成一行指令。它用 ACME 協議自動驗證「你確實控制這個域名」（通常是讓它連你的 server 或設一筆 DNS 紀錄），驗過就簽發，且能自動續期（憑證有 90 天效期）。

• 自己顧機器（VPS）：用 certbot 之類的工具，指令大致是 certbot --nginx -d example.com——它自動取得憑證、改好 nginx 設定、排程續期。
• 用 PaaS：平台通常自動幫你上憑證，你只要把域名指過去（設 CNAME）就有 HTTPS，完全不碰 certbot。

TLS 在哪裡「終結」

加解密這件事通常由 app 前面的一層代勞——nginx、負載平衡器、或 CDN 負責「TLS termination」：對外收 HTTPS、解密後用普通 HTTP 轉給後面的 app。所以你 app 本身常常只講 HTTP，HTTPS 是前面那層加上去的。反向代理 / LB 承擔這類職責的細節見 運行期維運 反向代理職責。

下一步

域名跟 HTTPS 接上，服務就「對外像個正常網站」了。接著是讓服務本身好部署、好搬家——見 十二要素基線。用 IaC 把 DNS 與憑證納管（Route53 + ACM）的進階做法見 Infra 核心服務。

設定進環境變數，不寫死在 code 裡

這是最重要的一條。資料庫位址、API 金鑰、外部服務 URL——這些每個環境都不一樣的東西，不能寫死在 code 裡，要從環境變數讀：

1# 不要這樣（寫死，換環境要改 code）
2db = connect("mysql://root:secret@localhost/app")
3
4# 要這樣（從環境變數讀，換環境只換變數）
5db = connect(env("DATABASE_URL"))

好處：同一份 code 在本機讀到本機的 DB、在 prod 讀到 prod 的 DB，不用改 code、也不會把 prod 密鑰簽進 git。密鑰怎麼安全注入見 Backend secret 治理。

process 無狀態，資料放外面

你的 app process 本身不存資料——使用者 session、上傳的檔案、快取，都放到外部的後端服務（DB、Redis、物件儲存），不放在 app 的記憶體或本機磁碟。

為什麼：這樣你才能隨時砍掉一個 app、重開一個、或同時開三個副本擋流量——因為資料不在 app 裡，砍了不會掉東西。這條是水平擴展的前提，深入見 運行期維運 無狀態設計。

log 輸出到 stdout，當成串流

不要讓 app 自己寫 log 檔、自己輪替。把 log 直接印到標準輸出（stdout），交給外面的平台去收集、儲存、查詢。這樣不管 app 跑在哪、幾個副本，log 都被統一收走，你不用去每台機器翻檔案。

明確宣告依賴、開機即用

app 依賴哪些套件，要寫在 lockfile 裡（package-lock.json、go.sum、requirements.txt），部署時照 lockfile 裝——不靠「機器上剛好有」。而且 app 要能快速啟動、優雅關閉（收到停止信號先處理完手上的請求再退），這樣部署新版、自動重啟才順。

dev / prod 儘量一致

本機開發環境跟線上環境的差距越小，「在我電腦上能跑、上線卻壞」的機率越低。這條在你用舊版 runtime 的 client 環境時特別關鍵——本機要對齊線上的版本與行為，見 Dotfile 模組十：Prod Parity。

判讀：這些不是潔癖，是省未來的痛

每一條都對應一個「沒做就會在某個時刻痛」的場景：設定寫死 → 換環境或輪替密鑰時要改 code、還可能把密鑰簽進 git；process 有狀態 → 想加一台擋流量卻發現 session 掉了；log 寫檔 → 出事要 SSH 進每台機器撈。還有一條上 PaaS 當天就會撞的：listen 在平台指派的 $PORT——Heroku / Cloud Run 這類平台會給你一個環境變數指定 port，app 沒讀它、寫死自己的 port，就部署失敗。第一次上線可以先抓住「設定進環境變數」跟「process 無狀態」這兩條（上 PaaS 再加 $PORT），其餘隨服務長大再補。

下一步

服務好部署了，接著常要決定「有狀態的那部分（資料庫）自己顧還是託管」——見 自架還是託管：以資料庫為例。config 注入與 runtime 設定的進階做法見 Backend 部署平台。

成本結構為什麼差

關鍵差別：VPS 上「DB 成本」不另計一條帳單，它跟 app 共用你本來就要付的那台機器；託管是另外一條帳單，而且每單位 RAM/CPU 比裸 VPS 貴很多，因為價格裡包了維運層。純算 compute，同一個小 DB，託管常是自架的好幾倍到十幾倍。

但「共用 VPS」不是真的零成本：DB（Postgres/MySQL）常態要 1–2GB+ RAM，跟 app 擠同一台小 VPS 容易 OOM 或 IO 互搶，實務上你得把 VPS 從 2GB 升到 4–8GB——那筆錢藏進了 VPS 帳單，只是不叫「DB 費用」。所以「便宜」要扣掉這段升規格的成本。

以下是量級、不是報價，且雲端定價會變、看區域規格——決策前一定要去各家定價計算機用你的實際規格算。

小專案常見的量級感：一台 2-4GB 的 VPS 全包月費個位數到二十幾鎂、DB 不另計；託管 DB 一個小 instance 一個月幾十鎂起、加儲存/備份/HA 後常落在幾十到上百鎂，而且是疊在 app 主機費用之上。

那多付的錢在買什麼

差價買的是你不做這些維運的代價：

• 自動備份 + 時間點還原（point-in-time recovery）
• 自動故障切換 / HA（主掛了自動起備）
• 版本修補、監控、read replica 一鍵開
• 半夜 DB 主機磁碟滿、掛掉時，有別人 on-call

在 VPS 上，以上每一條都是你的工作：你設備份、你測還原（沒測過的備份等於沒有，見 備份與還原的地基）、你修補、你處理 3am 事故；而且 VPS 一死、資料跟著死，除非你自己做了冗餘。

看 TCO，不看標價

• 標價：VPS 明顯便宜（DB 不另計帳單、頂多升一階規格 vs 託管一個月幾十上百）。
• 含你的時間 + 資料遺失風險 + 停機損失（總持有成本 TCO）：一旦資料有價值（有營收、賠不起），託管常常反而划算——省下的是你不用當 DBA、不用扛半夜事故、不用賭「我的備份真的能還原嗎」。
• 分水嶺：自用 / 早期 / 極度省錢 / 你享受搞維運 → 偏自架；有營收資料 / 小團隊時間值錢 / 賠不起資料遺失 / 沒人顧 DB → 偏託管。

這條「自架帳單便宜、但主要成本在帳單外的人力」跟 運行期維運 成本模型 講的「自建與託管人力差 3 到 10 倍」是同一件事；兩條成本曲線的交叉點怎麼算，見 運行期維運 自架 vs 雲端成本交叉點。

別掉進二選一

• 便宜 VPS（如 Hetzner）把自架成本壓很低，省錢派很有吸引力。
• 託管也有便宜檔：不是只有 RDS/Cloud SQL 這種貴的——DigitalOcean Managed DB、Supabase、Neon、PlanetScale 有便宜甚至免費方案，別把「託管」直接等於「昂貴」。
• Serverless DB（Aurora Serverless、Neon、PlanetScale）：流量低 / 尖峰型的按用量計費，離峰幾乎不花錢，小專案可能比固定 instance 更省。
• 折衷：DB 自架但放另一台獨立小 VPS（跟 app 分開、但不託管），隔離性有了、成本仍低。

為什麼「以資料庫為例」特別代表性

同樣的「自架 vs 託管」問題也發生在 cache、queue、物件儲存，但 DB 是最尖銳的——因為它有狀態、最怕資料遺失。也因此，商業 prod 幾乎不會在 container 裡跑正式 DB，而是用託管服務或獨立的資料節點（stateful 的保護與為何不隨手跑 DB container，見 Backend 狀態儲存選型）。無狀態的 app 可以隨便砍隨便開，有狀態的 DB 不行——這個差別決定了你多願意為「別人幫你顧它」付錢。

下一步

決定了哪些自己顧之後，凡是你自己顧的（尤其 DB），下一個必修是備份——見 備份與還原的地基。自建 vs 託管的完整選型理論見 Backend 模組零。

為什麼「沒測過還原的備份等於沒有」

備份會無聲地失敗：排程壞了沒人發現、備出來的檔案是空的或損毀、備了但少備了關鍵那張表、加密備份的金鑰弄丟了解不開。這些在你「需要還原」的那一刻才會爆——而那一刻通常是最糟的時刻（資料已經沒了）。

所以該有的紀律是：定期真的做一次還原演練——把備份拉到一個乾淨環境、還原、確認資料完整、app 接得上。演練同時量「還原花多久」——一份要跑半天才還原完的備份，對某些服務等於不可用，這個還原耗時就是還原時間目標（RTO）。演練過的備份才是資產，沒演練過的只是「你以為有」的安全感。各資料庫的還原演練實作見 vendor drills，如 PostgreSQL PITR 演練、MySQL 備份還原演練。

該備什麼、不該備什麼

備份的對象是「弄丟了重建不回來的東西」，不是全部：

• 要備：資料庫內容、使用者上傳的檔案、以及不在版控裡的 secret / 設定值來源（依十二要素 secret 不簽進 git、第三方 key 撤了就撤了，重建不回來）——這些是唯一副本，沒了就真沒了。
• 不用備：你的 app code（在 git 裡）、container image（在 registry 這個 image 倉庫裡）、能重跑一次就長回來的東西。這些有別的來源，備份它們是浪費。

判準：問「這東西弄丟了，我能不能從別的地方重建？」能 → 不用備；不能 → 要備。這也呼應十二要素的「process 無狀態、資料放外面」——正因為狀態集中在少數幾個地方（DB、物件儲存），要備份的範圍才清楚。

幾條地基原則

• 多久一次，看你賠得起丟多少：每天備 = 最多丟一天的資料。丟一天能接受就每天；不能接受就要更頻繁、或用能還原到任意時間點的機制（point-in-time recovery）。這個「能容忍丟多少」就是還原點目標的白話版。
• 備份別跟正本放一起：跟資料庫放同一台機器的備份，機器掛了兩個一起死。要放到不同機器 / 不同區域 / 不同供應商。常見的口訣是「3 份副本、2 種媒介、1 份異地」。
• 舊備份要留一段時間：只留最新一份的問題是——如果資料是幾天前就悄悄壞了、才發現，你最新的備份也已經是壞的。留一段歷史才能還原到「壞掉之前」。

這也是「自架 vs 託管」的一個關鍵差異

託管資料庫（RDS / Cloud SQL）把上面這些大部分自動化了：自動排程、異地儲存、point-in-time recovery、還原按幾個鍵。自己在 VPS 上跑 DB，這些全是你的工作——這正是自架 vs 託管那筆「帳單外成本」裡最重的一項。常被低估的就是這塊：DB container 跑起來很容易，備份、測還原、異地、保留策略才是難的部分。

下一步

備份是你自己顧任何有狀態元件時的底線。往上，接手一個別人留下的環境時，第一件事往往就是盤點「它到底有沒有能還原的備份」——見 Infra 接手：舊資料庫備份與遷移。

備份是自己顧任何有狀態元件的底線。往上的深度內容見各系列：服務選型理論 Backend 模組零、雲端地基 Infra、運維與成本 DevOps。